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PREFACE:    Role  of  ICST 


The  Institute  for  Computer  Sciences  and  Technology  (ICST) 
within  the  National  Bureau  of  Standards  (NBS)  has  a  mission  under 
Public  Law  89-306  (Brooks  Act)  to  promote  the  "economic  and 
efficient  purchase,  lease,  maintenance,  operation,  and 
utilization  of  automatic  data  processing  equipment  by  Federal 
departments  and  agencies,"  Thus,  ICST  pursues  a  number  of 
different  approaches  to  the  problem  of  application  development 
and  maintenance.  When  a  potentially  valuable  technique  first 
appears,  ICST  may  be  involved  in  research  and  evaluation.  Later 
on,  standardization  of  the  results  of  such  research,  in 
cooperation  with  voluntary  industry  standards  bodies,  may  best 
serve  Federal  interests.  Finally,  ICST  helps  Federal  agencies 
make  practical  use  of  existing  standards  and  technology  through 
direct  consulting  and  the  development  of  supporting  guidelines 
and  software. 


The  development  and  promotion  of  standard  programming 
languages  provide  an  especially  clear  example  of  this  cycle  of 
technological  development.  Through  its  activities  within  the 
Conference  on  Data  System  Languages  (CODASYL) ,  the  Institute  of 
Electrical  and  Electronics  Engineers  Computer  Society  (lEEE/CS) , 
the  International  Standards  Organization  (ISO) ,  and  committees 
accredited  by  the  American  National  Standards  Institute  (ANSI), 
ICST  has  contributed  to  the  design  or  standardization  of  most  of 
the  prominent  languages  in  use  today. 

Technical  work  within  such  organizations  helps  to  promote 
good  language  design.  ICST  represents  Federal  users'  interests 
by  striving  for  the  inclusion  of  language  features  which  exploit 
advances  in  programming  technology  and  software  engineering. 

Beyond  the  advantages  of  a  well-designed  language, 
standardization  per  se  is  valuable  for  several  reasons.  First 
and  foremost,  good  language  standards  make  it  easier  and  less 
costly  to  transport  software  from  one  language  processor  to 
another,  either  within  the  systems  of  a  given  vendor,  or  between 
vendors.  This  capability  is  valuable  not  only  for  programs 
written  by  end-users,  but  also  encourages  the  development  of 
vendor-independent  commercial  software.  Second,  standards  help 
to  preserve  the  value  of  programmers'*  skills  as  they  move  from 
one  installation  to  another.  There  is  no  need  for  extensive 
retraining  in  local  dialects  of  COBOL,  for  instance.  When  a  need 
arises  for  hiring,  there  exists  a  large  pool  of  programmers 
knowledgable  in  the  language.  Third,  programming  language 
standards  allow  the  development  of  standard  language  bindings  to 
various  application  facilities,  such  as  graphics,  communications, 
or  database.  Finally,  standards  provide  stability  to  the 
definition  of  a  language.  Thus,  the  large  base  of  Federal 
software  is  not  threatened  by  arbitrary  changes  in  language 
implementation.  Changes  are  introduced  in  a  controlled  way  and 
only  after  careful  evaluation  of  the  effect  on  existing  programs. 


Thus,  ICST  aims  to  achieve  a  reasonable  balance  between  the 
incorporation  of  improved  techniques  for  software  development  and 
maintenance  on  the  one  hand,  and  the  protection  of  existing 
applications  on  the  other.  Given  the  size  of  Federal  data 
processing  (DP)  operations,  the  achievement  of  such  a  balance  is 
a  critical  task.  Billions  of  dollars  are  at  stake,  both  in 
ongoing  development  and  maintenance  activities  and  in  the  base  of 
existing  software.  The  challenge  is  to  take  advantage  of 
potential  savings  in  the  former  while  minimizing  costs  for  the 
latter. 

When  ICST  determines  that  a  language  can  provide  important 
benefits  for  Federal  users,  and  that  a  technically  sound 
specification  exists,  it  recommends  the  language  to  the  Secretary 
of  Commerce  for  adoption  as  a  Federal  Information  Processing 
Standard  (FIPS)  [NBS75] ,  [NBS80] ,  [NBSSOa] .  The  reasons  for 
accepting  a  language  as  the  subject  of  a  FIPS  are  based  on  much 
the  same  criteria  as  described  below  for  language  selection.  The 
nature  of  the  language,  the  applications  typical  of  Federal 
users,  and  the  existing  base  of  programs,  machines,  language 
processors,   and  programming  skills  are  all  taken  into  account. 

When  a  FIPS  is  issued,  the  Federal  users  of  that  standard 
then  receive  a  number  of  support  services.  They  may  request 
official  Federal  interpretations  from  ICST  as  to  the  meaning  of 
the  standard  if  a  question  arises  about  a  particular 
implementation  [NBS81]  .  These  interpretations  are  developed  in 
cooperation  with  language  experts  in  Federal  agencies.  ICST 
works  closely  with  the  General  Services  Admininstra tion's  (GSA) 
Federal  Software  Testing  Center  (FSTC) ,  which  is  responsible  for 
the  validation  of  language  processors  claiming  to  conform  to  the 
FIPS.  FSTC  maintains  a  list  of  certified  language  processors 
[FSTC84]  which  have  undergone  validation.  Finally,  ICST 
participates  in  national  and  international  standards  activities 
for  the  FIPS  languages  and  stands  ready  to  assist  agencies  with 
various  language  issues,  such  as  the  applicability  of  a  language, 
technical  questions  about  the  meaning  of  a  standard,  and 
information  on  the  likely  development  path  for  a  given  language 
standard . 
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Volume  1  -  Overview 

John  V.  Cugini 
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ABSTRACT 

Programming  languages  have  been  and  will  continue  to  be  an 
important  instrument  for  the  automation  of  a  wide  variety  of 
functions  within  industry  and  the  Federal  Government.  Other 
instruments,  such  as  program  generators,  application  packages, 
query  languages,  and  the  like,  are  also  available  and  their  use 
is  preferable  in  some  circumstances. 

Given  that  conventional  programming  is  the  appropriate 
technique  for  a  particular  application,  the  choice  among  the 
various  languages  becomes  an  important  issue.  There  are  a  great 
number  of  selection  criteria,  not  all  of  which  depend  directly  on 
the  language  itself.  Broadly  speaking,  the  criteria  are  based  on 
1)  the  language  and  its  implementation,  2)  the  application  to  be 
programmed,   and  3)   the  user^'s  existing  facilities  and  software. 

This  study  presents  a  survey  of  selection  factors  for  the 
major  general-purpose  languages:  Ada*,  BASIC,  C,  COBOL,  FORTRAN, 
Pascal,  and  PL/I.  The  factors  covered  include  not  only  the 
logical  operations  within  each  language,  but  also  the  advantages 
and  disadvantages  stemming  from  the  current  computing 
environment,  e.g.,  software  packages,  microcomputers,  and 
standards.  The  criteria  associated  with  the  application  and  the 
user's  facilities  are  explained.  Finally,  there  is  a  set  of 
program  examples  to  illustrate  the  features  of  the  various 
languages. 

This  volume  contains  the  discussion  of  language  selection 
criteria.     Volume  2  comprises  the  program  examples. 


Key    words ;      Ada;      alternatives    to    programming;  BASIC;  C; 

COBOL!         FORTRAN;        Pascal;        PL/ I;        programming  language 

features;  programming  languages;  selection  of  programming 
language. 


*  Ada  is  a  registered  trademark  of  the  U.  S.  Government, 
Ada  Joint  Project  Office. 
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1.0     PURPOSE  AND  SCOPE 

Progranuning  is  a  means  to  an  end.  In  this  report,  we  shall 
assume  that  the  end  is  the  automation  of  some  function  performed 
by  an  individual  or  an  organization,  such  as  a  company  or  Federal 
agency.  The  question,  then,  is  "which  programming  language  is 
best  for  a  given  application?"  Any  discussion  of  programming  and 
programming  languages  must  consider  them  within  the  general 
context  of  data  processing.  It  is  not  enough  to  know  the  logical 
structure  of  the  various  languages.  In  order  to  make  informed 
choices,  we  must  also  take  into  account  such  factors  as 
portability,  the  availability  of  languages  in  various  computing 
environments  (e.g.,  main-frames  vs.  micros),  the  availability  of 
software  for  the  language,  and  so  on.  The  purpose  of  this  report 
is  to  present  and  explain  a  set  of  language  selection  criteria 
which  DP  managers  and  users  may  apply  to  their  particular 
situations.  These  criteria  apply,  of  course,  only  when  the 
language  of  implementation  is  important  to  the  user.  Conversely, 
if  the  user  is  purchasing  a  software  package  to  be  used  strictly 
as  is,  the  language  in  which  the  package  is  written  may  be  of  no 
concern. 

For  this  report,  the  scope  of  consideration  shall  be  limited 
to  conventional  programming  languages  as  the  means  for 
implementing  and  maintaining  an  application  system.  It  is 
important  to  understand  that  programming  is  only  one  among  many 
application  development  techniques.  Some  of  these  alternative 
techniques  are  described  in  Appendix  C.  Although  this  report 
focuses  on  issues  of  language  use  and  selection,  it  is  by  no 
means  implied  that  such  alternatives  are  to  be  ruled  out  in  favor 
of  a  conventional  programming  approach. 


2.0     PROGRAMMING  LANGUAGES  -  CRITERIA  AND  COMPARISON 

Choosing  the  appropriate  language  is  a  difficult  process 
because  there  are  such  a  large  number  of  relevant  factors.  The 
purpose  of  this  section  is  twofold:  first  to  enumerate  the  most 
significant  of  those  factors,  and  second  to  organize  them  in  such 
a  way  that  the  relationships  among  them  may  be  understood.  We 
will  group  language  selection  criteria  into  three  broad 
categories:  1)  the  properties  of  the  various  languages  and  of 
their  associated  software,  2)  the  nature  of  the  application  being 
programmed,  and  3)  the  characteristics  of  the  installation 
involved  in  the  work.  The  first  set  of  criteria,  based  on 
language  properties,  explain  the  features  offered  by  the 
different  languages.  These  features  must  then  be  evaluated 
against  the  requirements  imposed  by  the  application  to  be 
programmed  and  the  characteristics  of  the  installation. 

Language  and  application  issues  encompass  both  logical  and 
practical  considerations.  Logical  properties  are  those  that  are 
true  by  definition  of  the  object  in  question:  COBOL  is  defined 
to    have    fixed-point  decimal  arithmetic;     the  specification  of  a 


Page  2 


payroll  system  requires  that  one  of  its  functions  is  to  compute 
time-and-a-half  for  overtime.  Conversely,  it  is  a  practical 
consideration  that  COBOL  is  more  widely  available  than  SN0B0L4  or 
that  the  payroll  system  will  be  run  on  three  different  vendors' 
machines.  All  installation  characteristics  are  assumed  to  be 
practical.  Within  a  category,  logical  criteria  will  be  discussed 
first,   and  then  the  practical  criteria. 

This  distinction  between  logical  and  practical 
considerations  is  important,  since  much  of  the  literature  on 
language  usage  covers  only  the  logical  criteria.  This  is 
understandable,  in  that  the  matching  of  the  inherent  properties 
of  a  language  with  the  logical  definition  of  an  application  is 
rightly  seen  as  a  central  part  of  the  selection  process. 
Nonetheless,  DP  managers  operate  under  "real-world"  constraints, 
and  even  though  a  language  may  be  a  theoretically  perfect  match 
for  an  application,  there  may  be  mundane  but  effective  reasons 
(e.g.,  none  of  the  programmers  knows  the  language,  the  language 
is  unavailable  on  the  installation's  hardware)  for  making  another 
choice. 

Although  this  report  lists  and  explains  the  various  criteria 
to  be  taken  into  account,  it  is  up  to  each  organization  to  decide 
which  are  most  important.  For  any  given  application,  it  is 
unlikely  that  all  the  criteria  will  favor  one  language.  When 
weighing  conflicting  factors,  one  should  evaluate  both  long-term 
and  short-term  costs  and  benefits.  For  instance,  changing  from 
one  language  to  another  will  generate  costs  in  the  short  term, 
but  whether  these  costs  are  justified  depends  on  the  prospects 
for  ongoing  savings. 

This  report  will  cover  Ada*,  BASIC,  C,  COBOL,  FORTRAN, 
Pascal,  and  PL/I.  These  languages  were  chosen  because  they  are 
currently  the  most  used  by  Federal  agencies,  or  are  likely  to 
become  widely  used.  We  recognize  that  there  are  other  languages 
(ALGOL,  APL,  FORTH,  LISP,  MODULA,  MUMPS,  PROLOG,  SNOBOL,  etc.) 
with  certain  advantages,  but  these  are  either  oriented  to  some 
special  application  area  or  in  less  common  use  and  so  they  are 
not  included  here.  The  seven  languages  under  study  are  not  all 
approved  FIPS.  Please  see  the  preface  and  section  2.1.7  for 
details  on  the  role  of  FIPS  and  the  status  of  standards  for  these 
languages. 


2.1    Language  Factors 

This  section  will  compare  various  languages,  first  with 
respect  to  their  syntactic  and  semantic  features,  and  then  with 
respect  to  implementation  and  environmental  issues.  We  will 
describe  each  language  according  to  its  definition  in  the 
corresponding     ANSI     standard       ([Ada83],       [COB074]  ,       [FORT78]  , 

*  Ada  is  a  registered  trademark  of  the  Ua  S.  Government, 
Ada  Joint  Project  Office. 
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[Pasc8  3]  ,  and  [PL/176]).  In  the  case  of  BASIC  and  C,  a 
comprehensive  language  standard  does  not  yet  exist.  The  base 
documents     for  these  languages  are  given  in  [BASI84]   and  [Kern78] 

(see  section  2.1.7). 

There  is  an  ANSI  standard  and  a  FIPS  for  Minimal  BASIC,  a 
subset  of  the  language  considered  throughout  this  report. 
Although  many  implementations  conform  to  this  standard,  the 
language  it  describes  is  so  small  that  there  are  several 
implementor-def ined  enhancements.  For  C,  we  shall  assume  that 
the  standard  input/output  (I/O)  library  is  available,  but  not  the 
UNIX*  interface.  A  new  version  of  COBOL  is  currently  in  the 
approval  process  [COB083] ,  and  its  enhancements  over  the  current 
standard  are  noted.  Where  it  is  necessary  to  distinguish,  we 
shall  refer  to  these  two  versions  as  "COBOL-74"  and  "C0B0L-8x". 
Otherwise,  the  term  "COBOL"  may  be  assumed  to  apply  to  both 
versions.  Several  of  the  language  definitions  have  a  number  of 
levels  or  subsets  [PL/181]  .  In  general,  we  shall  compare  the 
most  complete  versions  which  are  defined,  and  disregard  lower 
levels  and  subsets. 


Bear  in  mind,  then,  that  the  status  of  the  languages  under 
scrutiny  varies  considerably.  There  are  as  yet  few 
implementations  of  and  little  experience  with  the  language 
specifications  for  Ada  and  BASIC.  At  the  other  extreme,  COBOL 
and  FORTRAN  assumed  their  present  shape  years  ago,  and  their 
advantages  and  limitations  are  by  now  apparent.  Although  draft 
standards  exist  for  BASIC  and  C,  these  have  not  been  formally 
adopted,   as  is  the  case  for  the  other  languages. 

It  should  be  noted  that  we  are  comparing  features  as 
directly  suppor ted  in  the  language.  Clearly,  most  features  can 
be  simulated  with  a  greater  or  lesser  degree  of  effort.  Thus, 
the  absence  of  a  logical  data-type  in  BASIC,  for  instance,  does 
not  prevent  a  programmer  from  setting  up  a  character  variable  as 
a  switch  and  assigning  "T"  or  "F"  to  it.  Nonetheless,  this  puts 
the  burden  on  the  user,  rather  than  the  language.  In  such  cases, 
then,  we  shall  simply  say  that  BASIC  does  not  support  logical 
data,  without  intending  to  preclude  the  possibility  of  achieving 
the  same  effect  some  other  way. 

Another  point  to  keep  clear  is  that  we  shall  be  concerned 
with  the  facilities  guaranteed  to  the  user  by  standard-conforming 
implementations  of  the  language,  whether  or  not  these  facilities 
are  built  directly  into  the  syntax  of  the  language,  or  provided 
indirectly,  via  standard  runtime  support.  For  our  purposes  then, 
we  shall  simply  say  that  both  Ada  and  COBOL  provide  sequential 
files,  even  though  they  are  provided  by  means  of  predefined 
generic  packages  in  Ada  and  directly  in  the  syntax  of  COBOL. 
Conversely,  we  shall  say  that  Ada  does  not  "have"  keyed  files, 
because  even  though  there  could  be  a  package  to  support  them,  no 
such  package  is  required  by  the  standard. 


*  UNIX  is  a  trademark  of  Bell  Laboratories. 
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This  survey  is  intended  to  convey  the  general  capabilities 
of  each  of  the  languages.  A  few  specialized  features  (e.g.,  the 
label  data  type  in  PL/I)  have  been  omitted  in  the  interest  of 
brevity. 

This  report  takes  a  comparative  approach  when  discussing  the 
languages:  they  are  measured  against  each  other  rather  than 
against  an  abstract  ideal.  Thus,  we  shall  emphasize  the  points 
at  which  a  given  language  differs  from  the  prevailing  pattern. 
Generally,  each  section  first  describes  the  capability  under 
consideration,  then  notes  the  typical  treatment  (if  any)  of  that 
capability,  and  finally  points  out  exceptions  to  the  typical 
case.  Many  of  the  sections  have  an  associated  figure.  These 
figures  normally  shou Id  not  be  used  in  isolation  from  the 
accompanying  text"!  Their  purpose  is  to  summarize  the  discussion 
and  serve  as  a  reminder  of  which  language  has  which  feature;  by 
themselves,   they  may  not  convey  fully  accurate  information. 

Unfortunately,  there  is  a  great  disparity  in  the  terminology 
used  by  the  various  language  communities  to  describe  similar 
concepts.  There  is  no  consistent  usage  for  terms  such  as 
"block",  "procedure",  "identifier",  or  "name",  e.g.  In  this 
guide  we  have  adopted  the  usage  judged  most  prevalent.  In  those 
sections  where  confusion  is  likely,  the  discussion  is  prefaced  by 
a  brief,  informal  definition  of  the  concept  in  question.  This 
definition  is  not  meant  to  be  authoritative,  but  merely  serves  to 
avoid  ambiguity. 


2.1.1    Syntactic  Style   (see  Figure  1)  - 

This  category  includes  those  features  of  the  language  which 
determine  the  general  appearance  of  the  program,  but  have  no 
direct  bearing  on  the  ability  to  express  control  or  data 
structures. 


2.1.1.1    Statement  Terminator  - 

A  statement  in  a  language  describes  a  single  action  or 
object.  Of  the  seven  languages,  only  FORTRAN  and  BASIC  use  an 
end-of-line  to  mark  the  end  of  a  statement.  For  the  other 
languages,  lines  are  not  logically  significant.  In  COBOL,  the 
beginning  of  a  statement  is  denoted  by  a  keyword  and  a  sequence 
of  statements,  called  a  sentence,  is  terminated  by  a  period 
(".").  All  the  others  use  a  semicolon  (";")  to  delimit 
statements.  Nonetheless,  all  langu^es  generally  encourage  the 
convention  of  coding  one  statement  per  line.  The  rules  for  using 
semicolons,  especially  within  compound  statements,  are  sometimes 
confusing  to  novice  programmers  and  so  the  ability  to  dispense 
with  them  favors  ease  of  writing. 
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2.1.1.2    Fixed  Or  Free  Format  - 

COBOL  and  FORTRAN  both  have  conventions  about  which 
character  position  in  a  line  of  source  code  must  be  used  for 
certain  syntactic  entities,  such  as  labels,  continuation,  or  the 
start  of  a  statement.  In  BASIC,  every  line  must  begin  with  a 
line  number,  starting  in  the  first  position.  Certainly  it  is 
desirable  that  programs  be  written  with  some  convention  for 
indenting?  whether  these  conventions  should  be  part  of  the 
language  is  questionable,  but  there  should  be  some  mechanism  for 
enforcing  an  orderly  style.  Language-based  editors  and 
pre ttypr inters  may  be  used  for  this  purpose. 


2.1.1.3     Statement  Labels  - 

FORTRAN,  BASIC,  and  Pascal  use  numbers  as  statement  labels. 
Clearly,  it  is  preferable  to  be  able  to  name,  rather  than  number, 
locations  within  the  code,   as  the  other  languages  allow. 


2.1.1.4     Identifiers  - 

Identifiers  (often  called  names)  are  syntactic  objects  used 
to  denote  various  kinds  of  entities  such  as  data,  types,  and 
procedures.  Only  FORTRAN  and  C  still  limit  identifiers  to  a 
small  number  of  characters  (six  and  eight,  respectively).  This 
is  also  a  problem  with  many  small  versions  of  BASIC,  some  of 
which  limit  the  user  to  a  mere  two  characters,  but  the  proposed 
standard  will  allow  31  characters.  Either  for  reading  or 
writing,  a  low  limit  on  the  length  of  identifiers  is  a  severe 
hindrance  to  good  programming.  Some  implementations  allow  a 
large  number  of  characters  but  only  the  few  first  are 
significant.  For  instance,  C  will  accept  more  than  eight 
characters,  but  may  not  recognize  these  additional  characters. 
This  approach  can  be  deceptive  and  counterproductive  because 
entities  that  appear  to  be  different  in  the  source  code  may 
actually  be  the  same. 

There  may  be  other  restrictions  on  identifiers.  Most  of  the 
languages  have  a  lengthy  list  of  reserved  words  which  must  not  be 
used  as  identifiers.  This  restriction  can  cause  confusion, 
especially  among  inexperienced  programmers.  FORTRAN  and  PL/I 
have  no  reserved  words,   and  BASIC  only  a  few. 


2.1.1.5     Implicit  Or  Declared  Entities  - 

Here  is  another  case  where  ease  of  reading  and  of  writing 
tend  to  be  opposed.  Clearly,  when  writing  it  is  easier  to  be 
able  to  assume  the  existence  of  entities,  such  as  variables,  as 
they     are    needed     in  the  algorithm.     This  is  allowed  in  FORTRAN, 
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BASIC,  and  PL/I.  On  the  other  hand,  by  requiring  a  program 
explicitly  to  declare  all  variables  before  they  are  referenced, 
COBOL,  Ada,  Pascal,  and  C  enforce  a  certain  discipline  that  may 
help  when  reading  a  program.  Perhaps  more  importantly,  this 
requirement  normally  causes  detection  of  the  common  programming 
error  of  misspelled  variable  identifiers. 

FORTRAN  and  BASIC  have  conventions  that  relate  the  spelling 
of  an  identifier  to  its  type,  e.g,  starting  an  integer  identifier 
with  "I"  or  ending  a  string  identifier  with  "$".  Such  self-typed 
variables  are  useful  in  that  they  need  not  be  explicitly  declared 
and  yet  their  type  is  apparent  throughout  the  program;  that  is, 
a  reader  need  not  refer  back  to  a  declaration  to  determine  the 
type.  FORTRAN  and  PL/I  have  a  facility  whereby  the  program  can 
set  its  own  default  typing  conventions  based  on  the  spelling  of 
identifiers. 


2.1.1.6    Program  Length  - 

COBOL,  and  to  a  lesser  extent,  Ada  and  PL/I,  encourage  a 
verbose  style;  FORTRAN  programs,  conversely,  tend  to  be  quite 
concise.  The  other  languages,  BASIC,  C,  and  Pascal,  fall 
somev^ere  in  between,  but  probably  closer  to  FORTRAN.  It  is  here 
that  we  find  a  direct  trade-off  between  ease  of  reading  and 
writing.  FORTRAN  and  BASIC  allow  the  programmer  to  get  something 
running  with  a  minimum  of  syntactic  overhead,  but  easily  become 
unreadable  unless  the  programmer  is  careful.  Conversely,  COBOL 
and  Ada  tend  to  be  quite  readable,  but  it  takes  a  fair  amount  of 
effort  to  produce  even  a  simple  program. 


2.1.2    Semantic  Structure  - 

Semantic  structure  encompasses  those  features  of  the 
language  which  allow  the  programmer  to  build  modules  in  the 
program  to  represent  algorithms  or  data  entities  or  both. 
Although  the  same  effect  can  often  be  achieved  without 
structures,  it  is  vital  that  the  language  allow  programs  to 
express  such  structures  in  a  natural  way;  this  is  important  both 
for  reading  and  writing  programs. 


2.1.2.1    Control  Of  Execution  (see  Figure  2)  - 

Control  of  execution  addresses  the  language  features  which 
describe  the  algorithmic  structure  of  the  program.  The 
programmer  uses  these  features  to  decompose  the  execution 
sequence  into  logically  related  groups,  so  that  the  underlying 
design  is  more  clearly  expressed. 
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2.1.2.1.1     Structured  Programming  - 

We  use  the  term  "structured  programming"  in  a  narrow  sense 
to  mean  simply  those  language  constructs  which  determine,  at  the 
detailed  level,  the  sequence  of  instruction  execution,  and  which 
encourage  the  development  of  well-organized  source  code.  Such 
features  have  found  their  way  into  virtually  all  the  languages. 
Except  as  noted  below,  all  languages  have  a  general  purpose 
if-then-else,  looping,  and  selection  (case)  construct.  FORTRAN 
is  the  weakest  in  this  regard;  it  has  no  single-exit  select 
construct,  and  its  looping  mechanism  depends  on  a  control 
variable,  not  an  arbitrary  condition.  COBOL-74^s  looping 
mechanism  currently  forces  the  performed  code  to  be  displaced  out 
of  the  normal  sequence,  but  the  proposed  new  standard  will  remedy 
this.  Other  problems  solved  by  the  C0B0L-8x  proposal  are  the 
need  for  a  delimiter  to  terminate  an  if-construc t,  but  not  the 
entire  sentence  (i.e.,  an  END-IF)  and  the  lack  of  a  selection 
construct. 

Ada,  BASIC,  and  C  have  a  statement  which  explicitly  exits 
the  current  loop;  this  is  useful  for  exiting  a  loop  in  a 
controlled  way,   rather  than  using  the  GO  TO. 


2.1.2.1.2    Blocks  - 

Blocks  allow  the  programmer  to  mark  off  certain  sections  of 
code,  such  that  it  is  treated  as  a  single  statement  and,  within 
the  block,  data  may  be  defined  locally  which  cannot  be  accessed 
from  outside  the  block.  Ada,  C,  and  PL/I  provide  full  block 
structure.  Pascal's  blocks  do  not  allow  the  definition  of  local 
data.     COBOL,  FORTRAN,  and  BASIC  do  not  provide  this  capability. 


2.1.2.1.3     Subroutines  - 

Most  languages  provide  a  way  to  write  subroutines  which  may 
be  invoked  from  one  part  of  a  program  and  then  perform  some  task 
or  operate  on  passed  parameters  to  return  the  results  of  the 
computation.  External  subroutines  may  be  separately  compiled, 
and  typically  communicate  with  their  invoker  through  the  passed 
parameters.  Internal  (or  nested)  subroutines  are  part  of  the 
same  compilation  unit  as  the  invoker  and  typically  have  direct 
access  to  the  invoker's  data,   as  well  as  to  their  own  local  data. 

C  does  not  provide  subroutines  as  such;  invoked  procedures 
are  always  external  functions  (see  2.1.2.1.4).  Moreover,  since 
parameter  passing  is  always  by  value,  the  programmer  must  pass 
pointers  if  the  function  is  to  communicate  results  back  to  the 
invoker,  i.e.,  passing  parameters  by  reference  is  not  provided 
directly,  but  must  be  simulated  by  the  program.  Pascal  is  weak 
in  that  it  does  not  provide  for  separate  compilation;  all  its 
subroutines    are  internal.     FORTRAN  has  no  mechanism  for  internal 
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subroutines,  COBOL-74  has  external  subroutines,  but  only  a  weak 
form  of  internal  subroutines  (invoked  with  PERFORM)  which  do  not 
accept  parameters  and  have  no  local  data.  C0B0L-8x  has  true 
internal  subroutines.  BASIC  has  internal  and  external 
subroutines,  but  the  only  local  data  for  its  internal  subroutines 
are  the  parameters,  Ada  and  PL/I  have  both  internal  and  external 
subroutines. 


2.1.2.1.4    Functions  - 

A  function  is  a  procedure  which  accepts  parameters  as  input 
and  returns  a  value.  It  is  normally  invoked  as  part  of  the 
evaluation  of  an  expression.  A  function  may  be  defined  by  the 
programmer  or  it  may  be  supplied  by  the  implementation  (so-called 
intrinsic  or  built-in  functions)  as  part  of  the  standard  run-time 
support.  For  user-defined  functions,  the  distinction  between 
external  and  internal  described  above  for  subroutines  also 
applies.  Only  COBOL  does  not  have  the  concept  of  functions.  All 
the  others  allow  the  user  to  define  such  functions  and  require 
some  elementary  functions  to  be  supplied  by  standard 
implementations  of  the  language.  Again,  Pascal  has  no  facility 
for  separate  compilation  of  such  procedures. 


2.1.2.1.5    Recursion  - 

Recursion  is  the  ability  of  a  procedure  (subroutine  or 
function)  to  invoke  itself,  either  directly  or  indirectly.  The 
definition  of  the  procedure  in  the  source  code  serves  as  a 
template  and  every  time  the  procedure  is  invoked,  the  logical 
effect  is  as  if  a  new  copy  of  the  procedure  (together  with  its 
data)  were  created  and  its  execution  initiated.  Recursion  is 
quite  valuable  for  several  classes  of  algorithms.  Only  COBOL  and 
FORTRAN  do  not  have  this  feature. 


2.1.2.1.6    Generic  Procedures  - 

A  generic  procedure  is  a  subroutine  or  function  defined  by 
the  user  which  is  capable  of  applying  the  same  algorithm  to 
parameters  of  different  types.  For  example,  a  procedure  which 
returns  the  largest  element  in  an  array,  regardless  of  the  type 
of  element  constituting  the  array,  could  be  written,  as  opposed 
to  having  to  write  a  separate  procedure  for  each  type.  Only  Ada 
and  PL/I  support  this  feature.  Both  allow  the  construction  of 
both  subroutines  and  functions. 
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2.1.2,1.7    Exception  Handling  - 

Exception  handling  is  the  ability  to  have  flow  of  control 
automatically  transferred  to  a  special  section  of  code  when  some 
anomalous  condition  arises  in  the  course  of  execution.  The 
section  of  code,  usually  called  the  exception  handler,  may  then 
attempt  some  remedial  action.  Languages  with  exception  handling 
define  a  list  of  exceptions  which  implementations  must  detect, 
each  identified  by  either  a  name  or  a  numeric  code.  Typical 
exceptions  are  division  by  zero,  numeric  overflow,  subscript  out 
of  range,   faulty  input,  etc. 

Ada,  BASIC,  and  PL/I  support  exception  handling.  Ada  and 
BASIC  syntactically  associate  an  exception  handler  with  a  body  of 
code  to  be  guarded;  PL/I  does  this  association  dynamically  by 
executing  an  ON  statement.  All  three  languages  have  a  special 
statement  which  artificially  causes  an  exception  of  a  given  type 
to  occur.  COBOL  has  a  less  general  capability  of  declaring  a 
procedure  to  be  used  upon  the  occurrence  of  certain  I/O 
exceptions.  Also,  COBOL  provides  a  SIZE  ERROR  clause  on 
arithmetic  statements  for  the  detection  of  truncation,  overflow, 
and  division  by  zero  and  on  the  CALL,  STRING,  and  UNSTRING 
statement  for  detection  and  correction  of  overflow. 


2.1.2.1.8    Concurrency  - 

Concurrency  (also  called  tasking  or  parallel  processing)  is 
the  ability  of  a  program  explicitly  to  designate  certain  sections 
of  code  to  be  executed  asynchronously.  Logically,  this  means 
that  such  parallel  processes  should  not  depend  on  each  other  for 
their  results  and  may  be  executed  in  any  order  relative  to  each 
other.  Typically,  there  is  also  a  mechanism  which  allows  the 
programmer  to  synchronize  these  otherwise  independent  processes. 
For  example,  if  task  3  needs  intermediate  results  from  tasks  1 
and  2,  task  3  can  be  made  to  wait  until  those  results  are 
available.  Physically,  concurrency  may  be  implemented  by 
interleaved  execution  on  a  single  processor,  or  by  true 
simultaneous  execution  on  a  multi-processor  system.  This  mode  of 
execution  is  in  contrast  to  the  usual  "single  thread"  flow  of 
control,  in  which,  at  any  given  time,  the  execution  of  a  program 
has  advanced  to  a  single  unambiguous  point. 

Only  Ada,  with  its  tasking  facilities,  and  BASIC,  with  its 
real-time  module,  provide  this  feature.  Note  that  COBOL  provides 
for  communication  between  asynchronous  processes  (section 
2.1.4.4),  but  does  not  provide,  in  the  language,  the  means  of 
generating  or  controlling  such  processes.  Although  the  FORTRAN 
standard  does  not  support  concurrency,  there  is  a  draft  standard 
for  Industrial  Real-Time  FORTRAN  [IRTF84] ,  developed  by  the 
European  Workshop  on  Industrial  Computer  Systems  Technical 
Committee  1  (EWICS/TCl)  and  reviewed  by  Working  Group  1, 
Programming  Language  for  the  control  of  industrial  processes 
(ISO/TC97/SC5/WG1) ,  which  is  currently  in     the    approval  process 


Page  12 


within  ISO/TC97/SC5  (see  2.1.4.3,  below).  This  draft  specifies 
standard  library  routines,  through  which  FORTRAN  can  perform 
parallel  processing. 


2.1.2.2     Control  Of  Data   (see  Figure  3)  - 

This  section  discusses  the  mechanisms  available  to  the 
programmer  for  establishing  the  logical  appearance  of  data  within 
the  program.  The  concern  here  is  not  with  actual  data  values  and 
operations,  which  are  covered  in  section  2.1.3.  Rather  this 
section  deals  with  the  extrinsic  characteristics  of  data,  such  as 
its  scope,   lifetime,  and  other  logical  properties. 


2.1.2.2.1    Storage  Classes  - 

Data  can  be  established,  stored,  and  deleted  in  various 
ways.  There  are  both  logical  and  physical  implications  of  each 
technique.  Usually,  data  is  associated  with  the  particular 
program-unit  (function  or  subroutine)  in  which  it  is  defined  and 
all  languages  have  rules  about  the  treatment  of  such  "local" 
data.  Typically,  data  declared  in  a  procedure  may  be  either 
static  or  automatic.  When  data  is  static,  its  value  is  retained 
between  invocations  of  the  procedure,  and  normally  storage  for  it 
is  allocated  only  once  before  execution  of  the  program.  In  the 
case  of  automatic  data,  each  invocation  generates  a  new  instance 
of  the  data,  and  the  usual  implementation  technique  is  for 
storage  to  be  allocated  and  de-allocated  for  each  entry  to  and 
exit  from  the  procedure. 

The  default  for  all  the  languages  is  automatic,  except  for 
COBOL,  in  which  the  default  is  static.  C,  FORTRAN,  and  PL/I 
support  static  data,  but  Ada,  BASIC  and  Pascal  do  not.  COBOL  has 
an  executable  statement,  CANCEL,  which  causes  a  fresh  copy  of  a 
designated  subroutine  to  be  used  at  the  next  invocation. 
COBOL-Sx  has  a  declarative  phrase,  INITIAL,  which  specifies  that 
the  program-unit  containing  it  is  to  be  initialized  upon  each 
entry.     Both  CANCEL  and  INITIAL  give  the  effect  of  automatic. 

The  languages  with  pointers  (see  2.1.3.2.5,  below),  Ada,  C, 
Pascal,  and  PL/I,  all  allow  the  program  explicitly  to  create  and 
destroy  multiple  instances  of  data  to  be  addressed  by  the 
pointer. 

PL/ I  also  has  a  storage  class,  CONTROLLED,  in  which  the 
program  explicitly  creates  and  destroys  instances  of  a  data-type 
according  to  a  stack  discipline  (last-in,  first -out).  C  has  a 
storage  class  REGISTER,  which  is  logically  similar  to  automatic, 
but  tells  the  compiler  to  attempt  to  maintain  the  data  item  in  a 
register  for  fast  access. 
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2.1.2.2.2    External  Data  - 

A  useful  feature  is  the  ability  explicitly  to  declare  some 
data  as  external  (also  called  common)  and  therefore  accessible  to 
the  entire  program,  including  external  subroutines  and  functions. 
Ada,  C,  C0B0L-8X,  FORTRAN,  and  PL/I  all  have  this  capability. 
COBOL-Sx,  FORTRAN,  and  PL/I,  however,  require  that  external  data 
be  declared  in  every  procedure  which  accesses  it.  Thus,  it  is 
external  in  the  sense  that  there  is  one  copy  of  the  data 
available  at  run-time,  but  not  in  the  sense  that  one  copy  of  the 
source  code  declarations  is  visible  throughout  the  program,  i.e. 
the  external  data  promotes  run-time  efficiency,  but  not  ease  of 
source  code  development.  COBOL- 7 4  does  not  support  external  data 
and  BASIC  allows  it  only  in  its  real-time  module,  not  in  the  core 
of  the  language.  Since  Pascal  doesn't  have  external  procedures, 
it  obviously  has  no  mechanism  for  setting  up  data  accessible  to 
such  procedures. 


2.1.2.2.3    Data  Abstraction  - 

Data  abstraction  is  a  feature  which  is  strongly 
characteristic  of  the  newer  languages.  Essentially,  it  is  the 
ability  to  describe  data  according  to  its  logical  (abstract) 
meaning,  rather  than  according  to  the  way  it  is  to  be  represented 
internally.  This  is  important  both  for  scalar  and  aggregate 
data.  Taking  a  simple  example,  to  define  a  data  item  as  FLOAT (6) 
merely  stipulates  that  the  item  will  contain  real  numbers  of  a 
certain  precision  as  values.  To  define  the  same  item  as  VELOCITY 
(where  VELOCITY  is  elsewhere  defined  as  FL0AT(6)),  preserves  more 
information  about  the  intended  use  of  the  item. 

We  can  distinguish  several  levels  of  capability  to  define 
data  abstractly.  The  most  basic  is  the  ability  to  give  a  name  to 
a  particular  data  type  and  thereafter  use  that  name  when  defining 
data  items.  This  has  two  advantages:  first,  data  items  are 
described  in  terms  of  their  logical  meaning,  rather  than  their 
physical  implementation  (VELOCITY  as  opposed  to  FL0AT(6)),  and 
secondly,  if  that  implementation  needs  to  be  changed,  it  can  be 
done  at  one  place  in  the  program  (e.g.,  by  changing  the 
definition  of  VELOCITY  to  FLOAT  (8)),  and  the  change  then 
automatically  propagates  throughout  the  program.  Ada,  C  (with 
its  TYPEDEF  clause)  ,  and  Pascal  all  have  this  capability. 

The  next  level  of  capability  is  for  the  language  to 
recognize  user-defined  types  and  automatically  provide 
type-checking  (see  2.1.3.1,  below)  and  some  operations,  such  as 
assignment  and  comparison,  for  them.  Ada  and  Pascal  provide 
these  features. 

Finally,  the  user  may  wish  to  define  new  operations  on  the 
data  type.  Ada  provides  many  features  to  support  this  ability. 
Pascal  supports  it  only  through  the  ability  to  define  functions 
and  subroutines,  using  the  new  data  type. 
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2.1.2.3    Packages  - 

If  we  view  semantic  structure  as  a  way  of  expressing  a 
program  according  to  its  logical  behavior,  rather  than  its 
physical  implementation,  then  packages  represent  the  highest 
level  of  abstraction.  In  packages,  there  is  no  need  to  declare 
operations  and  data  abstraction  separately.  Rather,  the  program 
can  define  logically  related  data,  data-types,  and  operations  (as 
specified  in  associated  subroutines  and  functions)  together  in  a 
package.  The  package  provides  a  logical  environment  which  can 
then  be  invoked  by  any  program,  or  part  of  a  program,  needing 
those  capabilities.  Packages  could  be  built  to  support  such 
facilities  as  indexed  files,  relational  databases,  graph 
manipulation,  rational  arithmetic,  and  so  on.  Only  Ada  provides 
packages. 


2.1.3    Data  Types  And  Manipulation  - 

Perhaps  the  most  salient  feature  serving  to  distinguish  the 
various  languages  is  the  choice  of  data  types  each  offers  and  the 
operations  available  on  that  data.  While  the  older  languages 
concentrated  on  providing  data  types  which  would  be  appropriate 
for  their  application  domain,  the  newer  languages,  Ada  in 
particular,  have  provided  mechanisms  for  the  user  to  define  his 
own  data  types.  This  strategy  has  the  advantages  of  user 
flexibility  and  language  economy,  but  the  penalty  of  requiring 
extra  work  for  the  user,  and  a  potential  degradation  of 
portability  (e.g.  ,  if  each  user  defines  fixed-point  decimal 
differently) .  This  section  will  consider  only  data  types  and 
operations  supplied  directly  by  the  standard  implementations  of 
the  language. 


2.1.3,1    Checking  And  Coercion  - 

Strict  type  checking  prevents  certain  classes  of  error  from 
being  committed  by  programmers,  in  that  the  language  allows  only 
some  carefully  restricted  combinations  of  data  types  and 
operations.  Thus,  type-checking  emphasizes  discipline  and 
control,  and  the  avoidance  of  surprising  results.  The 
disadvantage  of  this  approach  is  that  it  is  sometimes  awkward  to 
perform  operations  which  intuitively  seem  simple.  Conversely, 
type  coercion  allows  a  wide  variety  of  interaction  among  data 
types  (automatic  conversion)  ,  giving  the  user  more  power  and 
flexibility,  but  is  more  subject  to  misuse. 

Ada  and  Pascal  take  a  rather  strict  approach,  allowing  only 
a  very  few  coercions.  PL/I  is  at  the  other  extreme;  its 
specification  includes  very  complex  semantics  dealing  with 
conversion  rules.  The  other  languages  fall  somevAiere  in-between, 
allowing  certain  conversions,  but  forbidding  those  which  are 
plainly  mistaken. 
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2.1.3.2    Elementary  Data  - 

Elementary  data-types  (also  called  scalar)  are  those  which 
represent  a  single  indivisible  value,  as  opposed  to  aggregate 
types  (covered  below)  which  represent  some  combination  of  values. 
Normally,  the  language  standard  simply  describes  the  logical 
properties  associated  with  data  defined  as  a  certain  type,  but 
not  its  underlying  representation.  In  COBOL  and  PL/I,  however, 
the  programmer  may  describe  data  with  so-called  "pictures",  which 
imply  a  character-oriented  representation  of  the  data. 


2.1.3.2.1    Numeric   (see  Figure  4)  - 

All  the  languages  can  represent  numeric  data  in  some  form. 
PL/I  is  the  most  inclusive,  covering  all  the  types  specified  in 
the  other  languages.  All  the  languages  have  some  form  of 
floating-point  numbers,  except  COBOL.  Most  also  provide  a  second 
floating-point  type  with  extra  precision,  but  Pascal  does  not. 
BASIC  is  notable  in  that  its  longer  floating-point  type  is 
defined  in  terms  of  decimal.  Thus,  the  user  may  choose  between 
greater  accuracy  and  predictability  on  the  one  hand,  and 
execution  efficiency  on  the  other.  Fixed-point  numbers  are 
available  in  PL/ I,  Ada,  BASIC,  and  of  course  COBOL.  Ada's 
fixed-point  numbers  are,  however,  defined  as  binary,  rather  than 
decimal.  An  integer  type  which  permits  direct  binary  hardware 
implementation  is  available  in  all  the  languages  except  COBOL-74 
and  BASIC.  Of  course,  with  fixed-point  data  the  user  can  achieve 
the  logical  effect  of  integer  data.  Complex  numbers  are  provided 
only  in  FORTRAN  and  PL/I. 

All  the  languages  provide  the  four  elementary  arithmetic 
operations  (addition,  subtraction,  multiplication,  and  division), 
and  comparisons  (less-than,  etc.)  for  numeric  data.  C  and  COBOL 
are  unique  in  providing  special  syntax  for  incrementing  and 
decrementing  a  variable,  in  addition  to  the  general  capability  of 
assigning  the  value  of  an  arbitrary  expression  to  a  variable. 
Pascal  and  C  do  not  have  exponentiation,  and  Ada  provides 
exponentiation  only  to  an  integer  power.  Beyond  this,  there  is  a 
wide  variety  of  functions  provided  for  numeric  data.  BASIC, 
FORTRAN,  and  PL/I  have  a  large  set  of  supplied  functions, 
including  many  transcendental  functions  (hyperbolic, 
trigonometric  and  logarithmic).  Pascal  has  a  somev^at  smaller 
set,  but  still  including  some  trigonometries  and  logarithmics. 
Ada  provides  only  absolute  value  and  remainder  functions.  C  and 
COBOL  provide  none. 
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2.1,3.2.2    Character  (see  Figure  5)  - 

All  the  languages  provide  a  way  of  storing  characters.  Ada, 
Pascal,  and  C  use  arrays  to  handle  sequences  of  characters, 
whereas  the  other  languages  treat  the  string  as  a  special  type  of 
aggregate.  BASIC,  C,  and  PL/I  provide  direct  support  for 
variable-length  strings  (with  a  declared  or  default  maximum 
length);  in  the  other  languages,  character  strings  are 
inherently  fixed-length.  Pascal  has  very  limited  character 
manipulation;     only  assignment  and  comparison  are  provided. 

All  the  languages  except  Pascal  support  the  concatenation  of 
several  character  items  into  one  variable.  All  except  C, 
COBOL-74,  and  Pascal  allow  specification  of  a  substring  by 
position  (e.g.,  select  the  2nd  through  5th  character  in  a 
string).  The  proposed  C0B0L-8x  standard  provides  full  substring 
capability.  COBOL  and  PL/I  can  retrieve  (but  not  assign  to)  a 
substring  based  on  some  delimiter  in  the  string  itself  (e.g., 
select  everything  preceding  the  first  comma). 

BASIC,  COBOL,  FORTRAN,  and  PL/I  all  have  a  means  of 
searching  for  the  occurrence  of  a  character  string  within  another 
string.  C,  COBOL,  and  PL/ 1  provide  a  way  to  test  whether 
characters  are  alphabetic,  all  upper-  or  lower-case,  or  numeric. 
COBOL-Bx  and  PL/I  provide  a  facility  to  translate  systematically 
from  one  set  of  character  values  to  another  (e.g.,  translate  all 
A's  to  X,   all  B's  to  Y,   all  C's  to  Z). 

All  the  languages  (besides  Pascal)  provide  one  or  more 
mechanisms  to  convert  between  other  data-types  in  the  language 
and  equivalent  character  strings;  COBOL's  conversion  from  string 
to  number,  however,  requires  prior  specification  of  the  format  to 
be  converted  from.  Ada,  C,  FORTRAN,  and  PL/I  achieve  such 
conversions  by  pseudo-IO  statements,  which,  instead  of  accessing 
a  true  external  file,  access  a  string  variable.  Ada,  BASIC,  and 
PL/I  provide  conversion  functions.  COBOL  and  PL/I  do  many 
conversions  as  a  result  of  coercing  one  data-type  to  another  upon 
ass  ig  nmen  t. 


2.1.3.2.3    Logical  (see  Figure  6)  - 

Logical  data  is  capable  of  taking  on  only  two  values,  "true" 
and  "false",  and  serves  as  a  condition  which  can  be  tested  in 
various  control  statements.  Most  of  the  languages  have  such  a 
type  (also  called  boolean) ,  but  support  it  in  different  ways. 
Ada,  Pascal,  and  FORTRAN  support  this  type  directly.  BASIC  does 
not  have  logical  data.  COBOL  has  named  conditions,  which  can 
simulate  the  effect  of  logical  data.  C  uses  the  numeric  values 
of  zero  and  non-zero  to  stand  for  false  and  true.  Finally,  PL/I 
has  a  BIT  type  (see  below),  which  has  only  two  values,  0  and  1, 
and  which  can  be  used  as  a  direct  simulation  of  logical  data. 
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Except  for  BASIC  and  COBOL,  the  languages  allow  storing  the 
result  of  a  logical  expression  formed  from  logical  data  and 
operators.  All  the  languages  allow  combining  conditions  (as 
opposed  to  data)  with  the  logical  operators  and,  or,  and  not 
(conjunction,  disjunction,  and  negation)  .  Ada  also  has  the 
"exclusive  or".  FORTRAN  has  the  exclusive  or  and  logical 
equivalence.  PL/I,  in  addition  to  specific  syntax  for 
conjunction,  disjunction,  and  negation,  has  a  general  purpose 
BOOL  function  which  may  be  used  to  obtain  any  of  the  16  possible 
boolean  binary  functions. 


2.1.3.2.4     Bit   (see  Figure  7)  - 

Bit  data  is  capable  of  taking  on  only  two  values,  0  and  1. 
Normally,  bit  data  is  implemented  directly  on  the  hardware  bit 
structure  of  the  underlying  machine. 

Only  C  and  PL/I  support  bit  data.  As  mentioned  above,  PL/I 
also  uses  the  bit  type  as  its  logical  type.  Both  C  and  PL/I 
allow  bitwise  logical  operations  on  bit  aggregates  (i.e.,  the 
operation  is  performed  on  pairs  of  bits,  one  from  each  aggregate 
in  corresponding  positions),  such  as  logical  and,  or,  and  not.  C 
also  supports  the  exclusive-or  operation  and  shifting.  C  uses 
one  (integer)  machine  word  as  the  unit  for  bit-aggregation.  PL/I 
aggregates  bits  into  strings  of  arbitrary  length;  the  operations 
available  for  character  strings  (concatenation,  substring, 
search)  also  apply  to  bit  strings.  Also,  PL/I  provides  two 
functions,  SOME  and  EVERY,  which  test  whether  some  bit  or  every 
bit  in  a  string  has  a  value  of  1.  The  FORTRAN  standard  [FORT78] 
does  not  support  bit  data,  but  there  is  a  draft  standard  for 
Industrial  Real-Time  FORTRAN  [IRTF84]  which  does  provide  bitwise 
operations  on  integers,  much  like  C  (see  section  2.1.4.3,  below). 


2.1.3.2.5    Pointer  (see  Figure  8)  - 

Pointer  data  is  that  which  can  be  used  to  address,  or  point 
to,  other  data  objects.  It  is  useful  in  constructing  various 
kinds  of  dynamic  data  structures,  such  as  lists,  stacks,  trees, 
graphs,  and  queues.  The  ability  to  allocate  and  free  storage  is 
typically  associated  with  this  data  type  (see  2.1.2.2.1).  Ada, 
Pascal,  C,  and  PL/I  have  these  facilities;  BASIC,  COBOL,  and 
FORTRAN  do  not. 


2.1.3.3    Aggregate  Data  - 

Aggregation  is  any  mechanism  in  the  language  for  building  up 
a  data  structure  out  of  smaller  pieces,  such  as  smaller 
aggregates  or  elementary  data,  together  with  the  operations 
provided  to  manipulate  these  structures. 
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2.1.3.3.1    Arrays  (see  Figure  9)  - 

Arrays  are  ordered  collections  of  data  of  similar  type. 
Each  element  of  an  array  can  be  addressed  individually  according 
to  some  identifying  scalar  value  (usually  integer  values,  but 
sometimes  other  types  as  well)  .  Arrays  can  be  nested  so  as  to 
provide  the  effect  of  multidimensional  entities. 

All  the  languages  support  arrays  in  one  way  or  another. 
Only  Ada  and  Pascal  allow  addressing  by  other  than  integer 
values;  addressing  may  also  be  done  with  so-called  enumeration 
types  (any  type  with  a  set  of  discrete,  ordered  values)  .  BASIC 
and  COBOL-74  set  a  rather  low  limit  of  three  on  the  number  of 
dimensions  supported.  C0B0L-8x  will  allow  at  least  seven.  C  and 
COBOL  fix  the  lower  bound  subscript  of  arrays  to  0  and  1, 
respectively;  the  other  languages  allow  the  user  to  specify  a 
lower  bound.  Ada,  BASIC,  Pascal,  PL/ I,  and  COBOL  allow  simple 
array  assignment.  Comparison  of  two  arrays  (at  least  for 
equality)  is  allowed  only  by  Ada,  COBOL,  and  PL/I.  COBOL, 
however,  performs  these  operations  by  character,  not  by  element. 
C  and  FORTRAN  provide  no  array  operations. 

Because  of  the  potentially  large  number  of  values  involved, 
it  is  useful  to  be  able  to  initialize  arrays  other  than  by 
individual  assignment  to  each  element.  Ada,  C,  COBOL,  FORTRAN, 
and  PL/I  provide  a  way  of  initializing  arrays  with  a  list  of 
values  in  the  declaration  of  the  array,  although  the  COBOL 
mechanism  is  less  convenient  than  the  others.  C  allows  such 
initialization  only  for  external  or  static  arrays,  not  for 
automatic  arrays  (see  section  2.1.2.2.1).  Ada,  COBOL- 8x, 
FORTRAN,  and  PL/ 1  all  have  a  simple  way  to  set  all  elements  of 
the  array  to  a  single  value  in  the  array  declarartion.  The  Ada 
mechanism  for  initialization  can  also  be  used  in  executable 
statements.  Similarly,  BASIC^s  DATA  statement  can  be  used  for 
assigning  a  list  of  values  to  an  array  (albeit  within  a  loop) , 
and  COBOL- 8x  and  PL/ 1  can  set  all  the  elements  to  a  single  value 
during  execution. 

BASIC  and  PL/I  allow  arithmetic  and  string  operations  on 
arrays  as  a  whole,  as  well  as  by  individual  element.  For 
example,  the  program  may  multiply  the  elements  of  one  array  to 
those  of  another  and  store  the  result  in  a  third  array  with  a 
single  statement.  PL/I  always  does  such  operations 
element-by-element,  but  BASIC  treats  numeric  arrays  according  to 
the  rules  for  matrix  arithmetic. 

COBOL  is  unique  in  providing  a  statement  which  automatically 
searches  an  array  for  a  given  value.  If  the  array  is  ordered,  a 
binary,   as  opposed  to  linear,   search  can  be  performed. 
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2.1.3.3.2    Files  And  I/O  (see  Figure  10)  - 

Files  are  organized  collections    of    data     which  may  exist 

outside     the    program.       Operations    associated     with  files  are 

reading,  writing,  deleting  and  modifying  elements    of  the  file. 

The  latter  two  operations  are  often  not  available  for  sequential 
f  i  le  s . 


Sequential  files  are  those  in  which  the  data  exists  in 
linear  order  and  can  be  accessed  only  with  respect  to  the  current 
position  in  the  file  and  to  the  beginning  and  end  of  the 
sequence.  All  the  languages  support  sequential  files.  COBOL  is 
unique  in  providing  a  facility  to  sort  a  file  ordered  by  the 
contents  of  any  selected  fields,  generating  a  new  sequential 
file.  Also,  in  COBOL,  a  group  of  files  ordered  by  the  same 
fields  may  be  merged  to  form  one  ordered  file. 

Relative  files  (also  called  "direct")     are     those     in  which 

each    position     in     the  file  is  numbered  sequentially,   and  may  be 

accessed  by  means  of  the  identifying  number.  Only  C  and  Pascal 
do  not  support  such  files. 

Finally,  keyed  files  are  those  in  which  each  element  of  the 
file  has  an  associated  character  string  identifier,  called  its 
key.  The  normal  operations  for  keyed  files  are  the  ability  to 
access  individual  elements  by  key,  and  also  to  access  them 
sequentially  in  key  order.  BASIC,  COBOL,  and  PL/I  have  keyed 
f  i  les. 

A  file  may  be  broadly  classified  as  internal  or  external, 
according  to  the  nature  of  its  constituent  elements.  Elements  of 
internal  files  typically  are  some  type  of  data  aggregate,  often 
records,  with  logically  related  components  organized  in  one  or  a 
few  well-defined  formats.  They  are  usually  encoded  for  efficient 
I/O  operations  and  used  for  long-term  storage  of  data. 

All  the  languages  except  C  provide  internal  files.  COBOL 
and  PL/I  use  records  as  the  elements  of  the  file.  Ada  and  Pascal 
support  files  composed  of  any  defined  data-type,  including 
records.  BASIC  and  FORTRAN  simply  operate  with  lists  of 
variables  or  expressions  which  are  implicitly  treated  as  a  unit 
for  file  operations.  BASIC  also  has  a  TEMPLATE  which  can  be  used 
to  impose  a  fixed  format  on  the  list. 

External  files  are  display  oriented.  Their  elements  are 
usually  strings  of  characters,  called  lines,  in  either  fixed  or 
free  format.  Fixed  format  implies  that  the  program  explicitly 
specifies  the  representation  of  data  within  the  line  to  be  input 
or  output.  Free  format  implies  that  the  character  representation 
of  values  is  done  automatically  on  output,  and  scanned  and  parsed 
automatically  on  input.  Typically,  external  files  handle  only 
elementary  data,  not  aggregates.  They  are  useful  for  human 
interaction  and  for  data  interchange  between  systems  with 
different  internal  representations  of  non-character  data,  such  as 
floating-point  numbers. 
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Ada,  C,  FORTRAN,  and  PL/I  all  support  external  files  which 
may  have  a  fixed  or  free  format  both  on  input  or  output.  BASIC 
and  Pascal  do  not  have  a  mechanism  for  fixed  format  on  input. 
COBOL  does  not  provide  free  format  on  input  (not  counting  the 
ACCEPT  verb,  which  inputs  only  a  single  character  string),  a 
serious  impediment  to  interactive  applications.  The  only  free 
format  output  it  provides  (with  the  DISPLAY  verb)  may  not  be 
available  for  all  files.  Pascal  provides  free  format  input  only 
for  numbers,  not  for  booleans  or  character  strings.  All  the 
languages  except  FORTRAN  and  PL/I  provide  a  way  to  read  an  entire 
line  (whose  length  is  not  known  in  advance)  from  a  terminal  as  a 
single  character  string.  Ada,  C,  Pascal,  and  PL/I  are  all 
capable  of  reading  or  writing  part  of  a  line  as  a  single 
operation.  COBOL-74  and  FORTRAN  do  not  handle  partial  lines. 
BASIC  and  C0B0L-8x  can  write,  but  not  read,   a  partial  line. 

Finally,  some  languages  have  a  way  to  do  low-level  I/O,  in 
which  very  small  pieces  of  data,  such  as  individual  characters, 
can  be  manipulated.  Ada  provides  a  syntactic  framework  for 
low-level  I/O  which  is  fully  specified  in  a  device-dependent  way. 
Pascal  and  C  can  both  access  files  one  character  at  a  time. 


2.1.3.3.3    Records  (see  Figure  11)  - 

Records  (also  called  "structures")  are  a  way  of  grouping 
together  logically  related  data  of  different  types.  Very  often, 
file  I/O  is  performed  at  the  record  level.  Internal  operations 
normally  associated  with  records  are  assignment,  comparison,  and 
p  arame  te  r-pass  ing . 

Only  BASIC  and  FORTRAN  do  not  have  a  record  type  such  as  to 
allow     internal  operations.     The  operations  allowed  on  records  in 
C  are  quite  limited;     in  particular,  I/O  cannot  be    done    at  the 
record     level,     nor  are  any  of  the  internal  operations  available. 
C  manipulates  records  almost  solely  through  the  use    of  pointers 
to     those     records.      The    pointers    can,  of  course,  be  assigned, 
compared,  and  passed  as  parameters.     Ada,  COBOL,  Pascal,  and  PL/I 
all    allow  record  assignment  and  parameter  passing.     In  addition, 
COBOL  and  PL/I  allow  assignment    between    elements    of  different 
types    of    records,   based  on  the  correspondence  of  names  of  those 
elements.     Pascal  does  not  have  record  comparison;     Ada  and  PL/I 
allow    comparing     only     for  equality  or  inequality;     COBOL  allows 
ordered  comparisons  (less-than,  etc.)  as  well,     treating  records 
as  character  strings. 

Most  of  the  languciges  support  variable-format  record 
definitions  (possibly  of  different  lengths)  for  the  same  area  of 
storage;  this  is  needed  for  handling  files  with  formatted 
records,  but  more  than  one  such  format.  Ada  and  Pascal  provide  a 
record  definition  wherein  the  contents  of  a  particular  field 
(often  called  the  record  tag)  determines  which  of  several  formats 
applies.  C,  COBOL,  FORTRAN  and  PL/I  simply  allow  re-defining  the 
same     area,     leaving  control  to  the  programmer.     FORTRAN  also  has 
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"left-tabbing"  to  permit  re-interpre tation  of  the  same  input 
field.  BASIC  handles  the  problem  not  through  a  record 
definition,  but  by  providing  for  reading  only  part  of  a  record 
and  then  re-reading  it. 


2.1.3.3.4     Sets   (see  Figure  12)  - 

A  set  is  an  unordered  collection  of  elements  chosen  from  a 
specified  universe.  The  usual  operations  associated  with  sets 
are  testing  whether  an  element  belongs  to  a  set,  inserting  or 
deleting  an  element,  testing  whether  one  set  is  a  subset  of 
another,  and  taking  the  union,  intersection,  difference,  or 
negation  of  sets.  Also,  it  is  possible  to  express  a  literal 
value  to  be  assigned  or  compared  to  a  set  variable  with  a  set 
constructor , 

Only  Pascal  directly  supports  the  concept  of  a  set.  BASIC, 
COBOL,  and  FORTRAN  do  not  support  this  type  at  all.  The  other 
languages  have  features  which  permit  a  rather  direct  simulation 
and  so  we  shall  discuss  them  here  even  though  their  facilities 
are  defined  at  a  less  abstract  level.  Bit  strings  can  be  used  in 
PL/I  (to  simulate  sets  of  integers  only)  ,  arrays  of  booleans  in 
the  case  of  Ada,  and  C  has  bitwise  operations  on  integers  along 
with  the  ability  to  define  bit-fields.  In  the  case  of  C  and 
Pascal,  the  size  of  the  universal  set  can  be  quite  small,  often 
limited  to  the  word  size  of  the  machine.  Although  not  all 
operations  are  directly  supported  by  these  four  languages,  it  is 
usually  straightforward  to  express  a  missing  operation  in  terms 
of  those  provided,  e.g.,  the  set  difference,  A  -  B,  can  be 
computed  as  A  AND  (NOT  B)  .  Ada,  C,  and  PL/I  all  directly  support 
unary  negation,  but  not  set  difference,  nor  subset  testing. 
Conversely,  Pascal  supports  difference  and  subset  testing,  but 
not  negation. 


2.1,4    Application  Facilities  (see  Figure  13)  - 

Application  facilities  characterize  the  major  semantic 
functions  of  a  language  beyond  those  associated  with  particular 
data-types.  Also,  these  facilities  tend  to  be  closely  related  to 
the  external  entities  upon  which  the  program  operates  and  thus 
visible  to  the  end-user,  as  opposed  to  the  internal  features  of 
the  language,  visible  only  to  the  programmer. 


2,1.4.1    Reports  - 

Only  COBOL,  with  its  report  writer  facility,  directly 
supports  the  generation  of  reports.  The  essential  feature  of 
report  writer  is  that  the  report's  format  is  declared  statically, 
rather  than  generated  as  the  result  of  an  explicit  algorithm. 
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2.1.4.2    Database  - 

While  many  language  interfaces  to  database  facilities  are 
commercially  available  (especially  for  COBOL  and  FORTRAN),  no 
standard  currently  exists  for  such  interfaces.  Standardization 
work  is  furthest  advanced  for  COBOL.  ANS  committee  X3H2  has 
primary  responsibility  for  database  standards  within  the  U.S.  It 
may  be  expected  that  when  X3H2  completes  its  work  on  a  database 
standard,  bindings  to  the  various  languages  will  follow  shortly 
[Gall84]  . 


2.1.4.3    Real-time  - 

Real-time  applications  are  those  in  which  the  program  is 
controlling  some  activity  for  which  time  is  an  important 
constraint,  not  simply  in  the  sense  of  completion  of  the  task, 
but  that  the  progress  of  the  activity  is  tied  to  true  physical 
time.  Typical  examples  are  the  control  of  machinery  in  a  factory 
or  of  devices  in  vehicles  such  as  aircraft.  This  is  in  contrast 
to  such  applications  as  file  processing,  in  which  only  the 
logical  behavior  is  important  and  there  is  no  strong  dependence 
on  physical  time. 

To  support  such  applications,  a  language  must  have  a  way  of 
expressing  relationships  to  real  time  (either  absolute  time  or 
duration)  and  handling  asynchronous  events,  such  as  interrupts. 
Also,  such  applications  usually  involve  concurrency  (see 
2.1.2.1.8,  above).  Only  Ada,  with  its  tasking  facility,  and 
BASIC,  in  its  real-time  module,  support  real-time  applications. 
As  mentioned  above  in  the  section  on  concurrency,  there  is  a 
draft  standard  for  Industrial  Real-Time  FORTRAN  [IRTF84] ,  which 
provides  real-time  support. 


2.1.4.4    Communication  - 

Communication  is  the  ability  for  one  process  to  pass 
information  to  another  process  which  may  be  executing 
asynchronously.  One  process  is  a  sender  and  the  other  a  receiver 
of  a  message.  The  actual  transmission  of  the  message  may  occur 
at  the  same  time  for  both  processes,  or  the  system  may  accept  a 
message  from  a  sender  and  transmit  it  later  to  a  receiver.  Only 
Ada,  BASIC  (in  its  real-time  module),  and  COBOL  provide  this 
facility.  Ada  and  BASIC  use  synchronized  messages  (send  and 
receive  at  the  same  time) ,  while  COBOL  allows  queueing  of 
messages. 
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2.1.4.5     Graphics  - 

Graphics  is  the  capability  of  manipulating  visual  objects 
and  properties,  such  as  locations,  lines,  two-  or 
three-dimensional  shapes,  and  colors.  Typically,  the  main 
interest  is  in  generating  displays  on  a  graphics  screen,  and 
accepting  information  from  such  a  screen  in  terms  of  an  indicated 
location  or  area.  ANS  committee  X3H3  has  primary  responsibility 
for  graphics  within  the  US  and  they  work  closely  with  the 
international  standardization  efforts  of  ISO/TC97/SC5/WG2 .  The 
BASIC  standard  incorporates  a  set  of  facilities  from  the  ISO 
draft  standard  for  graphics.  Work  is  under  way  for  bindings  of 
most  of  the  other  languages  to  the  draft  standard,  with  FORTRAN 
being  the  farthest  advanced. 


2.1.5     Program  Implementation  Control  - 

Some  of  the  languages  have  features  which  enable  the 
programmer  to  control  the  compilation  and  execution  process,  so 
as  to  tailor  a  program  to  a  given  machine,  or  to  some 
optimization  goal.  These  features  differ  from  those  described 
earlier  in  section  2,1  in  that  their  primary  goal  is  not  to 
define  the  logical  behavior  of  the  program;  nonetheless,  that 
behavior  is  sometimes  affected.  The  use  of  these  features  is  not 
without  cost.  By  their  nature,  they  usually  involve  non-portable 
code.  Some  of  their  functions  could  be  performed  using  system 
control  commands,  thus  limiting  the  program  to  a  purely  logical 
description  of  the  application.  On  the  other  hand,  they  do 
provide  a  somev^at  vendor-independent  way  of  specifying  common 
implementation  options. 

Ada  has  a  quite  extensive  set  of  facilities  to  control  the 
way  programs  are  implemented.  The  two  mechanisms  provided  are 
so-called  pragmas  and  representation  clauses.  Pragmas  are 
available  to  tell  the  compiler  about  the  memory  size  of  the 
machine,  to  optimize  storage  space  or  time  in  general,  and  to 
optimize  storage  for  chosen  data  items,  among  other  functions. 
Representation  clauses  tell  the  compiler  how  to  map  certain 
logical  entities  in  the  program  to  the  underlying  machine 
architecture. 

BASIC  has  an  OPTION  statement,  some  clauses  of  which  are 
logical  in  nature,  but  two  have  efficiency  implications.  The 
program  can  specify  the  use  of  the  standard  ASCII  collating 
sequence  for  character  comparison,  or  of  the  possibly  different 
native  sequence.  Also,  the  ARITHMETIC  option  determines  whether 
numeric  operations  will  be  performed  according  to  a  decimal  model 
defined  in  the  standard,  or  an  undefined  native  model. 

COBOL' s  CONFIGURATION  SECTION  has  clauses  to  tell  the 
con^iler  about  available  memory  and  to  define  the  character 
collating  sequence.  The  segmentation  feature  tells  the  system 
how  to  overlap  storage  when  executing  the  program.     The  USAGE  and 
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SYNCHRONIZATION  clauses  determine 
data     items.       Certain  physical 
areas  may  be  specified  in     the  I 
SECTION. 


the  hardware  representation  of 
properties    of  files  and  buffer 
-0-CONTROL    paragraph    and  FILE 


Pascal's  only  feature  for  program  implementation  control  is 
the  packed /unpacked  attribute  for  data  (packed  implies  using  less 
storage  than  unpacked).  There  is  a  compiler  directive, 
"forward",  which  is  not  for  program  implementation  control  (it  is 
a  syntactic  device  to  declare  the  existence  of  a  procedure 
farther  on  in  the  program) ,  but  implementors  may  define  their  own 
directives  for  such  purposes,  much  like  Ada's  pragmas. 

PL/I  provides  an  OPTIONS  statement,  but  the  standard  does 
not  define  any  particular  options  -  this  is  left  to  implementors. 
For  describing  files,  PL/I's  ENVIRONMENT  attribute  allows  the 
specification  of  implementation-dependent  characteristics.  Data 
items  may  be  specified  as  ALIGNED  or  UNALIGNED,  directing  that 
data  be  either  aligned  on  a  storage  boundary  (usually  implying 
faster  access)  ,  or  packed  together  regardless  of  boundaries  (and 
therefore  using  less  space)  . 

As  mentioned  in  section  2.1.2.2.1,  C  has  a  storage  class 
REGISTER,  which  informs  the  compiler  to  keep  the  data  item  stored 
in  a  register  for  fast  access,   if  possible. 

FORTRAN  has  no  facilities  for  program  implementation 
control. 


2.1.6     Simplicity  - 

Language  simplicity  is  difficult  to  measure  quantitatively, 
although  there  have  been  some  attempts  [Hals77]  .  We  shall  rely 
on  the  intuitive  notion  that  a  language  with  relatively  few 
semantic  concepts  and  syntax  rules  is  simpler  than  one  which 
embodies  several  more  sophisticated  concepts,  and  more  complex 
syntactic  expressions.  Simplicity  is  not  good,  per  se  -  complex 
applications  will  likely  require  a  complex  language.  Simplicity, 
however,  makes  for  easier  learning  and  fewer  errors  in  actual 
use.  Certainly,  the  goal  is  that  a  language  be  as  simple  as 
possible,  given  the  semantic  domain  it  must  cover. 

BASIC  is  the  simplest  language  under  study.  There  are  only 
two  data  types  available  within  a  given  program,  variable-length 
strings,  and  numbers.  It  is  possible  to  perform  I/O  operations 
with  simple  defaults  that  require  no  formatting.  The  convention 
of  one  statement  per  line  avoids  some  pitfalls  that  may  arise 
with  statement  separators  and  terminators. 

FORTRAN  and  C  also  allow  the  writing  of  comparatively  short, 
straightforward  programs,  although  there  is  a  bit  more  syntactic 
overhead  than  with  BASIC. 
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Pascal  is  somev^at  more  complex.  Its  structure  is  very 
regular,  which  contributes  to  simplicity,  but  it  requires 
relatively  elaborate  declarations,  and  its  rules  governing 
statement  groupings  and  separators  can  lead  to  subtle  program 
errors. 

Finally,  Ada,  COBOL,  and  PL/I  must  be  rated  as  the  most 
complex  of  the  languages.  This  is  understandable,  given  the 
applications  for  which  they  were  designed.  Nonetheless,  it 
requires  substantially  greater  effort  to  master  all  the  rules 
governing  the  use  of  one  of  these  languages. 


2.1.7     Standardization  (see  Figure  14)  - 

The  advantages  of  standardization  have  already  been  covered 
in  the  preface  and  need  not  be  repeated  here.  Factors  which 
support  language  standardization  include  the  existence  of  a 
formally  sanctioned  specification,  present  and  future 
availability  of  conforming  implementations,  and  a  mechanism  for 
conformance  testing  of  language  processors.  Also  relevant  to 
standardization  is  the  availability  of  software  tools  to  monitor 
the  conformance  of  programs  to  a  language  standard  -  see  section 
2.1.10.1,  below. 

Of  the  languages  covered  in  this  report,  COBOL  and  FORTRAN 
are  the  most  thoroughly  standardized.  They  have  long  been  the 
subject  of  ANSI  standards  activities,  and  conforming 
implementations  are  widespread  throughout  the  industry. 
Furthermore,  they  have  been  adopted  as  FIPS,  and  implementations 
are  subject  to  validation  by  the  General  Service  Administration's 
Federal  Software  Testing  Center  (GSA/FSTC)  .  Although  there  are 
ongoing  efforts  to  revise  these  ANSI  standards,  it  is  likely  that 
future  versions  will  be  substantially  compatible  with  the  current 
specifications.  Note  especially  that  the  revision  of  COBOL  is  in 
the  later  stages  of  the  approval  process  within  ANSI  and  ISO 
[COB083]  ,  ICST  is  actively  considering  the  adoption  of  this  new 
version  of  COBOL  as  a  FIPS. 

Pascal  and  Ada  are  both  recently  adopted  (1983)  ANSI 
standards  and  so  there  are  fewer  conforming  implementations  than 
for  COBOL  and  FORTRAN.  It  is  highly  likely  that  conforming 
implementations  will  become  widely  available.  Fortunately, 
neither  language  has  been  subject  to  great  differences  in 
implementation,  in  the  case  of  Pascal  because  the  original  Pascal 
report  [Jens74]  served  as  a  de  fac to  standard,  and  in  the  case  of 
Ada,  because  the  standard  preceded  actual  implementations.  At 
the  time  of  this  report,  ICST  is  actively  considering  the 
adoption  of  Ada  and  Pascal  as  FIPS.  Validation  tests  are 
available  for  both  languages.  In  the  case  of  Ada,  these  are 
formally  administered  by  the  Ada  Validation  Organization. 
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The  British  Standards  Institution  (BSI)  offers  a  Pascal 
Compiler  Validation  Service.  These  tests  however,  are  based  on 
the  ISO  standard  for  Pascal  [IS083] ,  not  the  ANSI  standard.  The 
ISO  standard  has  two  levels,  level  0  being  substantially  the  same 
as  the  ANSI  standard,  and  level  1  including  an  additional  feature 
(conformant  arrays)  which  allows  an  invoked  procedure  to  accept 
an  array  of  any  size  as  a  parameter. 

There  has  been  an  ANSI  standard  for  PL/I  since  19  76. 
Although  those  implementations  developed  since  that  time  have 
generally  followed  the  standard,  there  have  been  relatively  few 
such  implementations.  No  conprehensive  validation  tests  are 
available.  In  1981,  an  ANSI  standard  was  adopted  for  a  subset  of 
PL/I,  and  this  appears  to  be  gaining  more  acceptance,  not  only 
among  mainframes  and  minis,  but  also  for  micros.  Nonetheless,  it 
must  be  said  that  standardization  for  PL/I  has  not  been  as 
effective  as  for  the  languages  discussed  above.  The  future 
prospects,   especially  for  the  full  language,   are  uncertain. 

There  is  an  ANSI  standard,  which  has  been  adopted  as  a  FIPS, 
for  Minimal  BASIC,  a  very  small  subset  of  the  language  considered 
throughout  this  report.  FSTC  is  performing  validations  for  the 
Minimal  BASIC  standard.  Although  many  implementations  conform  to 
this  standard,  the  language  it  describes  is  so  small  that  there 
are  many  imp lemen tor-defined  enhancements.  Furthermore,  unlike 
Pascal  and  Ada,  in  the  absence  of  a  de  fac to  standard,  large 
differences  have  evolved  in  BASIC  implementations.  The  proposed 
standard  for  a  complete  version  of  the  language  should  help 
remedy  this  situation,  but  full  standardization  is  coming  to 
BASIC  much  later  than  to  COBOL  and  FORTRAN.  As  a  result  it  will 
be  a  few  years  before  the  support  for  the  BASIC  standard  can  be 
as  comprehensive  as  for  other  languages.  The  experience  with 
Minimal  BASIC  gives  grounds  for  optimism,  but  the  acceptance  of 
full  BASIC  as  a  standard  is  not  as  assured  as  for  Ada  or  Pascal. 

Finally,  development  of  an  ANSI  standard  for  C  has  begun 
only  recently.  Like  Pascal,  the  existence  of  a  de  facto  standard 
[KernTS]  has  helped  forestall  wide  divergence  in  implementation, 
but  there  are  some  differences,  especially  in  the  runtime 
library.  Indeed,  one  of  the  outstanding  questions  is  the  degree 
to  which  a  C  standard  will  be  divorced  from  UNIX  runtime  support. 
No  comprehensive  validation  test  set  yet  exists.  It  is  too  early 
in  the  process  to  be  able  to  estimate  the  acceptance  of  a  C 
standard . 


2.1.8    Performance  - 

Strictly  speaking,  performance  is  a  characteristic  of  a 
given  implementation  of  a  language,  not  of  a  language  as  such. 
Nonetheless,  the  nature  of  a  language  often  encourages  a  certain 
type  of  implementation  strategy.  For  instance,  language  design 
usually  presents  the  problem  of  trading  off  a  large  number  of 
features      against    compiler    size    and     speed.      As    a  language 
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implementation  consumes  more  machine  resources,  it  becomes  more 
expensive  to  implement  a  given  application.  Resources  include 
both  storage  and  time  and  may  be  consumed  during  various  phases 
of  processing,  such  as  interpretation,  compilation,  and 
execution.  The  relationship  between  language  and  performance  may 
be  complex.  For  instance,  a  higher  level  language  feature  such 
as  assignment  of  entire  arrays  may  place  a  greater  burden  on  the 
compiler,  yet  also  facilitate  run-time  optimization.  Of  course 
the  relative  importance  of  compiler  efficiency  vs.  execution 
efficiency  depends  on  the  application. 


Generally  speaking,  C,  FORTRAN,  and  Pascal  require 
relatively  few  resources.  These  languages  were  designed  for  both 
easy  compilation  and  rapid  execution. 

BASIC  is  often  implemented  with  an  interpreter,  which  of 
course  implies  diminished  overhead  (no  compilation)  ,  but  slow 
execution.  BASIC  compilers  are  available,  however,  and  such 
implementations  may  be  expected  to  be  roughly  comparable  to 
FORTRAN  in  performance. 

The  design  goals  for  Ada  are  just  the  opposite  as  for  an 
interpreter.  Given  the  elaborate  mechanisms  for  declarations  and 
for  linking  packages  together,  compilation  is  likely  to  be  rather 
expensive.  Ada  programs  are  supposed  to  operate  in  a  real-time 
environment,  however,  and  execution  should  be  fairly  efficient, 
although  some  run-time  detection  of  exceptions  may  be  expensive. 
Judgments  about  Ada's  performance,  however,  must  be  tentative, 
pending  the  accumulation  of  experience  with  actual 
implementations. 

Finally,  COBOL  and  PL/I,  as  the  largest  languages  under 
study,  have  a  relatively  high  cost  for  compilation  and  execution, 
especially  compilation.  There  are  implementations  of  lower 
levels  of  COBOL,  and  of  the  PL/I  subset;  these  implementations 
have  an  improved  level  of  performance,  as  suggested  by  the  fact 
that  they  run  on  mini-  and  microcomputers. 


2.1.9     Software  Availability  - 

Sometimes,  the  easiest  way  to  develop  a  program  is  to  buy 
one  that  has  already  been  written.  To  the  extent  that  re-usable 
and  supported  code  is  available  in  one  language  rather  than 
another,  it  becomes  advantageous  to  use  that  language,  especially 
if  the  purchased  software  must  interact  with  user-written 
programs . 

Ada,  as  a  new  language,  does  not  have  a  significant  software 
base.  The  design  goals  of  the  language,  however,  place  great 
stress  on  re-usability  of  code,  as  epitomized  in  Ada's  "package" 
feature.  It  is  reasonable  to  expect  that,  as  the  language  comes 
into  use,  a  good  deal  of  software  will  be  available. 
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Almost  all  systems  programming  for  UNIX  is  done  in  C,  and 
hence  there  are  many  system  routines  available  in  that  language 
which  may  be  accessed  through  the  library  mechanism,  when  C  is 
running  under  UNIX, 

There     are    many     application    packages     (see    Appendix  C) 
available       in      COBOL,     covering     most    common    data  processing 
functions.     It  is  often  possible  to  buy     a    complete  application 
outright  and  then  simply  tailor  and  maintain  the  code. 

FORTRAN,  as  the  dominant  language  for  scientific  and 
engineering  applications,  has  extensive  packages  and  libraries  in 
those  areas.  Especially  in  the  field  of  mathematical  software, 
the  base  for  FORTRAN  is  extremely  strong. 

In  the  realm  of  microcomputers,  BASIC  software  currently 
predominates.  The  spectrum  of  applications  includes  both 
business  data  processing  and  some  mathematical  software.  BASIC 
software,  however,  is  likely  to  be  more  dependent  on  a  particular 
system  or  implementation  than  the  languages  just  mentioned, 
because  of  the  slow  pace  of  standardization. 

Pascal  and  PL/I  offer  less  support  in  the  area  of  existing 
software,  probably  because  the  major  application  areas  were 
pre-empted  by  the  earlier  languages.  Some  Pascal  software  is 
available,  however,   in  the  microcomputer  arena. 


2,1.10     Software  Development  Support  - 

A  very  important  consideration  in  comparing  languages  is  the 
availability  of  software  tools  and  features  which  assist 
programmers  in  the  construction  and  maintenance  of  programs. 
Although  some  of  these  features  are  embedded  in  the  languages 
themselves,  they  are  discussed  here  because  they  do  not  affect 
the  logical  behavior  or  the  performance  of  operational  programs; 
rather,  their  main  purpose  is  to  facilitate  the  human  process  of 
software  development  and  maintenance.  Software  development 
support  can  also  be  implemented  as  part  of  a  compiler  or  as  an 
external  package  -  see  [Houg82]  ,  [Shah82]  ,  and  [NBS83]  .  An 
external  tool  may  apply  to  only  one  language,  or  it  may  be 
language- independent. 

It  is  difficult  to  present  a  detailed  comparison  of  the 
languages  with  respect  to  availability  of  software  aids.  That 
availability  changes  over  time,  and  depends  strongly  on  the 
vendor  -  neither  factor  a  property  of  the  language  per  se.  The 
following  generalizations  give  an  overall  perspective,  but  users 
are  advised  to  make  detailed  inquiries  when  assessing  support  for 
a  given  language. 

Ada,  as  a  new  language,  is  not  yet  strongly  supported  by 
software  tools,  but  it  is  a  central  part  of  the  Department  of 
Defense  plan  for  Ada  to  sponsor  the  development  of  a  broad  range 
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of  such  tools.  It  is  a  reasonable  expectation  that  software 
support  will  become  widespread  as  Ada  is  adcpted  and  implemented. 

Many  microcomputer  implementations  of  BASIC  treat  the 
language  as  an  integral  part  of  the  system,  and  as  such  offer 
editing  and  debugging  support  (see  below). 

COBOL  and  FORTRAN,  benefitting  from  their  position  as  older 
standardized  languages,  have  a  wide  variety  of  commercially 
available  software  support,  although  this  is  very  often 
vend or -dependent.  GSA/FSTC  offers  some  vendor-independent  tools 
to  Federal  agencies  for  COBOL. 

Software  development  support  for  C,  Pascal,  and  PL/I  is  less 
extensive  than  for  the  other  languages.  Particular  operating 
systems  may  offer  extra  support,  however.  For  instance,  there 
are  several  C-oriented  facilities  in  UNIX,  and  MULTICS  provides 
tools  for  PL/I. 


2.1.10.1    Source  Code  Manipulation  And  Checking  - 

This  category  covers  all  facilities  which  are  directly 
involved  in  the  development  and  modification  of  source  code. 
Some  languages  have  built-in  features  to  incorporate  pre-written 
sections  of  code.  This  is  extremely  useful  for  implementing  such 
practices  as  standard  data  descriptions  for  files,  etc.  COBOL's 
COPY  feature  has  long  been  used  for  this  purpose.  C's  "# include" 
and  PL/I^s  "%INCLUDE"  provide  similar  capability.  Ada's  package 
facility  (see  2.1.2.3,  above),  while  more  comprehensive  than  mere 
source  inclusion,  nonetheless  can  perform  much  the  same  function. 
C's  "#define"  statement  and  C0B0L-8x's  REPLACE  statement  cause 
systematic  substitution  of  tokens  within  the  source  code.  For 
instance,  an  identifier  can  be  uniformly  changed  throughout  the 
program. 

External  to  the  languages  are  such  features  as  editors, 
pre ttypr inters,  and  library  managers.  The  UNIX  command  "cb",  for 
example,  performs  pre ttypr in ting  for  C  programs.  Library 
managers  are  especially  useful  in  large  development  projects 
involving  many  programs.  They  help  keep  track  of  such  matters  as 
which  versions  of  code  have  been  compiled,  which  modules  depend 
on  others,  etc.  It  is  anticipated  that  a  sophisticated  library 
management  system  will  be  available  for  Ada.  This  is  reflected 
in  the  standard's  requirements  regarding  compilation. 
Language-based  editors  are  a  relatively  new  and  extremely 
promising  development.  Such  editors  incorporate  many  of  the 
syntax  rules  of  the  language  and  thus  are  capable  of 
automatically  generating  syntactically  correct  code  in  response 
to  user  commands.  Typically,  the  code  produced  will  also  follow 
built-in  conventions  for  indenting  and  grouping  of  entities,  i.e. 
the  usual  pre  ttypr  inter  functions. 
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Finally,  tools  are  available  which  check  source  code  for 
adherence  to  language  standards  and  conventions.  Some  tools 
allow  individual  installations  to  establish  and  enforce  their  own 
conventions.  Others,  often  built  into  compilers,  monitor  code 
for  conformance  to  the  ANSI  standard.  The  FTPS  for  COBOL  and 
FORTRAN  require  that  vendors  provide  this  facility  with  their 
language  processors  when  selling  to  the  Federal  Government.  The 
ANSI  standards  for  Ada  and  Pascal  also  require  implementations  to 
be  capable  of  syntax -check  ing .  In  the  UNIX  environment,  the 
program  "lint"  performs  a  portability  check  on  C  programs. 
Finally,  there  is  a  utility  [Hopk8  3]  to  do  the  same  for  Minimal 
BASIC  (not  the  proposed  full  version)  . 


2.1.10.2    Program  Testing  - 

Software  aids  in  the  area  of  testing  come  from  all  three 
sources  of  software  tools:  language-embedded,  compiler-embedded, 
and  external.  These  aids  are  used  to  detect  syntax  and  logic 
errors  in  programs,   but  not  to  generate  correct  code. 

Only  two  languages,  BASIC  and  COBOL,  have  debugging 
statements.  The  effect  of  these  statements  can  be  turned  off  and 
on,  with  a  run-time  switch  in  BASIC  and  a  compile-time  or 
run-time  switch  in  COBOL.  They  allow  the  user  to  trace  the 
effect  of  execution,  and  so  help  diagnose  problems.  C  has  a 
related  feature,  conditional  compilation,  which  allows  the  user 
to  tell  the  compiler  whether  to  ignore  or  compile  sections  of 
code;    clearly,  this  can  be  of  use  in  debugging. 

As  mentioned  earlier,  software  development  features  usually 
depend  on  the  vendor,  rather  than  the  language.  BASIC  is  unique, 
however,  in  that  it  is  very  often  implemented  with  an 
interpreter.  It  is  then  quite  common  to  find  interactive 
debugging  provided.  Such  features  as  being  able  to  interrupt  and 
resume  execution,  or  to  pause  and  display  the  current  contents  of 
variables  are  typical  in  an  interpretive  environment. 

Compiler  and  run-time  diagnostics  can  be  of  great  value  when 
testing  code.  [Shah8  2]  covers  many  of  the  common  features. 
Especially  for  those  languages  without  exception-handling 
(section  2.1.2.1.7),  it  is  important  that  the  system  provide 
useful  information  when  encountering  anomalous  run-time 
conditions.  Some  vendors  provide  debugging  facilities,  often 
geared  to  interactive  program  development,  which  apply  to  all  the 
languages  implemented  on  their  system.  Of  course,  compile-time 
diagnostics  should  also  be  easy  to  understand  and  should  be 
helpful  in  identifying  problems.  There  are  some  rather 
sophisticated  tools  available  for  such  functions  as  analysis  of 
system  dumps,  static  and  dynamic  control  flow  analysis,  test 
coverage,  etc.  See  [Houg82]  for  a  full  description.  Most  of 
these  tools  are  oriented  to  FORTRAN  or  COBOL. 
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2,1.10.3    Information  And  Analysis  - 

Compilers  and  external  utilities  can  also  be  useful  in 
analyzing  both  the  logical  and  performance  characteristics  of 
programs.  Such  facilities  as  cross-reference  tables  for 
identifiers,  statistics  on  the  uses  of  different  types  of 
statements,  object  code  listings,  and  statistics  on  storage  and 
time  usage  are  all  helpful  in  solving  logic  problems,  and 
analyzing  performance.  Again,  it  is  difficult  to  draw  any 
general  conclusions  about  the  availability  of  such  tools  for  the 
various  languages,  other  than  to  point  out  the  predominance  of 
COBOL  and  FORTRAN  as  objects  of  such  facilities. 


2.2    Application  Requirements  (see  Figures  15  And  16) 

Now  that  we  have  examined  what  the  languages  under  study 
have  to  offer,  we  shall  look  at  the  criteria  for  analyzing  the 
application  requirements.  We  shall  proceed  from  those  criteria 
most  closely  bound  up  with  the  logical  definition  of  the 
application  in  question,  to  those  determined  by  the  environment 
in  which  it  is  to  be  implemented.  The  description  of  each 
criterion  will  refer  back  to  those  language  features  most 
relevant  to  that  requirement.  The  overall  relationship  between 
application  requirements  and  language  factors  is  summarized  in 
Figure  15. 


2.2.1    Functional  Operations  - 

The  most  basic  requirement  is  the  ability  to  perform  the 
operations  involved  in  the  application.  For  instance,  does  the 
application  use  fixed-point  or  floating-point  calculation?  Is 
there  a  great  deal  of  character  string  manipulation?  Will  the 
application  need  interactive  graphics?  These  requirements  are 
most  commonly  expressed  by  characterizing  the  application  as 
"business-oriented"  (implying  fixed-point  decimal  arithmetic, 
character  manipulation,  and  file-handling)  or  "scientific" 
(implying  array  manipulation  and  numerical  calculation).  While 
these  descriptions  have  validity  for  some  applications,  they  are 
often  oversimplifications.  Systems  analysts  and  designers  should 
carefully  determine  the  full  array  of  needed  operations  and 
functions,  and  not  rely  too  heavily  on  the  use  of  two  or  three 
simple  categories. 

The  language  features  most  relevant  to  these  requirements 
are  the  data  types  and  application  facilities.  When  no  one 
language  appears  adequate  to  the  task,  users  should  consider  a 
multi-language  approach  -  although  there  are  associated  costs, 
especially  because  of  the  lack  of  standardization  of 
inter-language  capabilities.  Bearing  in  mind  their  limitations, 
we  can  make  some  broad  generalizations  about  the  suitability  of 
the  various  languages  for  certain  classes  of  application. 
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Figure  15  -  Language  Factors  vs.  Application  Requirements 
(see  section  2.2) 

This  figure  illustrates  which  language  factors  are  most 
relevant  in  fulfilling  the  various  application  requirements. 
"XX"  indicates  that  the  factor  is  strongly  supportive  of  the 
requirement;  "X"  indicates  a  less  important  factor  in  satisfying 
the  requirement. 
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For  information  processing  applications  (business-type) , 
COBOL  is  clearly  the  language  of  choice.  BASIC  and  PL/I,  as  well 
as  COBOL,  support  decimal  arithmetic,  character  manipulation,  and 
sophisticated  file-handling,  and  are  therefore  also  reasonable 
choices.  BASIC^s  lack  of  a  record  construct  (see  2.1.3.3.3) 
hanpers  its  use,  especially  for  more  complex  applications. 

FORTRAN  offers  the  strongest  support  for  scientific, 
mathematical,  and  engineering  applications,  especially  in  the 
extensive  software  available  for  purchase.  PL/I  and  BASIC  should 
be  considered,  in  that  they  have  a  large  assortment  of  built-in 
functions,  extended  precision  floating-point  numbers,  and  array 
manipulation.     PL/I  supports  conplex  numbers  as  well. 

Ada,  C,  and  PL/I  are  suitable  for  systems  programming,  in 
that  they  are  typically  implemented  so  as  to  allow  fairly  direct 
access  to  the  underlying  machine,  although  only  Ada  directly 
supports  parallel  processes  (tasking) . 

Real-time  applications  (other  than  systems  programming)  may 
be  handled  by  Ada  or  BASIC.  If  the  proposed  standard  for 
Industrial  Real-Time  FORTRAN  (see  section  2.1.4.3)  becomes  widely 
accepted,  FORTRAN  would  also  be  a  sensible  option. 

For  educational  applications,  it  is  important  that  a 
language  allow  clear  and  simple  expression  of  the  concepts  being 
taught.  BASIC,  for  elementary  concepts  of  computers  and 
programming,  and  Pascal,  for  more  theoretical  topics,  are  the 
most  suitable  choices.  Of  course,  education  was  the  original 
design  goal  of  both  languages. 


2.2.2    Size  And  Complexity  - 

This  criterion  is  concerned  with  the  size  and  complexity  of 
the  application  (and  presumably,  therefore,  of  the  programs) ,  to 
be  implemented.  While  size  and  complexity  are  not  necessarily 
linked,  they  are  discussed  together  because  the  same  language 
features  which  help  to  manage  one  also  help  to  manage  the  other. 
Size  is  self-explanatory  -  number  of  lines  of  code  may  be  taken 
as  an  adequate  metric.  An  application  may  be  complex  as  a  result 
of  especially  sophisticated  algorithms  or  data  structures,  or 
because  modules  within  the  application  interact  in  a  large  number 
of  ways.  Real-time  applications  tend  to  be  more  complex  than 
those  with  sequential  control.  Similarly,  the  updating  of  master 
files  and  databases  is  more  complex  than  read-only  operations. 

For  large,  complex  applications,  language  features  which 
support  the  creation  and  maintenance  of  code  (software 
availability  and  development  support)  or  help  the  programmer  to 
express  complex  relationships  (program  structure)  are  especially 
relevant.  Ada  is  noteworthy  as  a  language  which  had  the 
development  of  large,  complex  systems  as  an  explicit  design  goal, 
and  many  features  of  Ada  reflect  that  goal.     PL/I    also  provides 
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useful  features  for  attacking  large  applications,  COBOL  is 
strong  in  the  variety  of  software  tools  conmiercially  available 
for  managing  development  and  maintenance. 

Conversely,  for  small  (<  250  lines),  simple  applications,  it 
is  desirable  to  use  a  language  which  does  not  incur  an 
unnecessarily  large  syntactic  and  conceptual  overhead. 
Simplicity  therefore  becomes  a  crucial  property.  BASIC  and 
FORTRAN  are  good  choices  for  such  applications.  Pascal  and  C  are 
we  11 -suited  for  intermediate  sized  programs. 


2.2.3    Number  Of  Programmers  - 

To  the  extent  that  a  program  or  system  is  to  be  developed  or 
maintained  by  several  individuals,  it  becomes  important  that  the 
code  be  readily  understandable.  Language  features  in  the 
categories  of  program  structure,  standardization,  and  software 
development  support  are  clearly  relevant.  The  strong  languages 
in  this  area  are  Ada  and  COBOL.  PL/I  also  has  helpful  features, 
but  suffers  from  weak  standardization. 


2.2.4    Expertise  - 

Unless  an  agency  has  the  option  of  hiring  new  programmers, 
it  must  reckon  with  the  skills  of  its  current  staff.  Using  an 
unfamiliar  language  will  incur  costs,  either  for  training  or  for 
having  the  work  performed  on  contract.  It  is  important  to 
balance  short-term  costs  against  potential  long-term  gains.  If 
there  is  likely  to  be  an  ongoing  need  for  programmers  skilled  in 
a  given  language,  training  can  be  a  sound  investment.  And,  of 
course,   some  languages  are  much  easier  to  learn  than  others. 

Managers  should  also  take  into  account  whether  the 
application  is  to  be  implemented  by  professional  programmers, 
i.e.,  those  whose  primary  job  is  programming,  or  by  casual 
programmers  -  those  for  whom  programming  is  a  secondary  skill. 
With  the  spread  of  microcomputers,  casual  programming  is  becoming 
more  common.  Such  programming  is  best  done  in  a  relatively 
simple  language,  but  also  in  a  language  which  provides 
application  facilities  directly  to  the  user,  since  casual  users 
should  not  be  expected  to  construct  their  own  from  more  primitive 
features.     BASIC  and  FORTRAN  are  usually  the  best  choices. 

Professional  programmers  typically  can  make  good  use  of  more 
sophisticated  features.  Ada,  COBOL,  and  PL/I  are  more  oriented 
to  this  type  of  practice.  Pascal  and  C  are  intermediate  cases; 
C,  although  relatively  simple,  is  appropriate  for  systems 
programmers.  Typically,  programming  in  C  involves  the 
construction  and  use  of  sophisticated  libraries  of  system 
functions  from  C's  simple  repertoire  of  features. 
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If  new  programmers  are  to  be  hired,  then  the  available  pool 
of  programmers  skilled  in  a  language  becomes  an  important 
consideration.  One  key  advantage  to  strong  standardization  is 
the  creation  of  such  a  reservoir  of  expertise.  Currently,  COBOL 
and  FORTRAN  are  most  widely  known  among  professional  programmers. 
Pascal  and  BASIC  are  being  used  in  educational  environments,  and 
hence  are  also  well-known. 


2.2.5    End -user  Interaction  - 

Batch  processing  can  be  equally  well  handled  by  all  the 
languages.  Interactive  processing,  however,  requires  language 
features  to  support  that  type  of  I/O  operation.  Also,  it  is 
important  that  the  run-time  performance  be  adequate  for  quick 
response  to  user  actions. 

BASIC  strongly  supports  interactive  applications,  both  in 
its  I/O  and  in  having  graphics  capabilities.  Also,  the  proposed 
standard  defines  helpful  run-time  recovery  in  case  of  invalid 
input.  COBOL  does  not  provide  good  I/O  support  for  free  format 
data.  Pascal  also  is  weak  in  this  regard.  All  the  other 
languages  can  perform  reasonably  well. 


2.2.6    Reliability  - 

Certain  applications  perform  critical  functions  which 
require  a  great  deal  of  reliability.  Many  real-time  applications 
fall  into  this  class.  An  application  involving  the  transfer  of 
large  sums  of  money  is  another  example.  Program  structure 
features,  especially  exception-handling,  help  meet  this 
requirement.  Type  checking  is  also  thought  to  be  useful  in  early 
detection  of  certain  kinds  of  error.  Software  development 
support  and  language  simplicity  can  contribute  to  the 
construction  of  correct  programs. 

As  with  size  and  complexity,  reliability  was  one  of  the 
major  design  goals  for  Ada,  and  consequently  Ada  offers  the 
strongest  support  for  this  goal,  although  its  complexity  may 
contribute  to  errors  among  less  experienced  programmers.  BASIC 
has  only  a  few  simple  data  types  and  exception  handling,  so  it 
too  is  a  good  choice,  Pascal  offers  strong  type  checking,  but  no 
exception  handling;  PL/I  offers  exception  handling  but  very 
little  type  checking. 
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2.2.7    Timeframe  - 

Some  programs  are  written,  executed  a  few  times,  and  then 
discarded.  Others  become  part  of  a  system  which  may  be 
operational  for  decades.  Clearly,  ease  of  writing  is  a  dominant 
concern  in  the  first  case,  and  ease  of  reading  in  the  second. 
Even  for  long-lived  systems,  however,  development  requirements 
may  differ.  Sometimes  there  is  a  need  for  prototyping  to  get 
some  operational  capability  quickly?  or,  schedules  may  allow 
more  time  for  pre-implementa tion  design.  Program  structure, 
simplicity,  software  availability,  and  software  development  all 
pertain  to  these  goals.  Also,  the  trade-off  between  compilation 
and  run-time  performance  will  affect  the  two  cases  differently. 
Finally,  strong  standardization  is  much  more  important  to  a 
system  with  a  long  lifetime  than  to  a  short-term  effort,  since  it 
is  very  possible  that  the  system  will  outlive  the  hardware  on 
which  it  is  originally  implemented. 

For  rapid  development,  BASIC,  FORTRAN,  and  to  a  lesser 
extent,  C,  are  appropriate,  with  their  emphasis  on  simplicity  and 
low  syntactic  overhead.  Also,  users  can  take  advantage  of  the 
considerable  body  of  existing  software  available  in  these 
languages.  For  long-lived  systems,  Ada,  COBOL,  Pascal,  and  PL/I 
are  usually  better  choices,  with  their  emphasis  on  more  detailed 
declarations  and  elaborate  compilation. 


2.2.8     Portability  - 

Portability  is  used  here  in  the  narrow  sense  of  being  able 
to  re-use  source  code  on  different  systems.  A  typical  case  in 
which  there  is  a  strong  requirment  for  portability  would  be  a 
central  design  agency  writing  code  to  be  run  at  various  field 
installations.  Of  course,  the  achievement  of  portability  always 
depends  strongly  on  proper  management  and  coding  practices  on  the 
part  of  the  user;  the  language  alone  cannot  guarantee  such  a 
result. 

Clearly,  standardization  is  the  key  criterion  for  this 
requirement.  At  present,  the  strongest  language  standards  are 
for  Ada,  COBOL,  FORTRAN,  and  Pascal;  in  the  case  of  C,  there  is 
relatively  strong  de  fac to  standardization. 


2.2.9    Execution  Efficiency  - 

Some  applications  place  heavy  demands  on  hardware  resources 
once  they  are  in  operation.  Examples  are  systems  with  high 
transaction  rates,  very  large  files  or  databases,  and  lengthy 
numerical  calculations.  Meeting  such  requirements  is  largely  a 
matter  of  adequate  hardware,  but  language  performance  and  the 
ability  to  guide  compilers  to  efficient  implementation  are  also 
helpful.     Ada,  C,  FORTRAN,  and  Pascal  are  likely     to    yield  more 
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efficient  execution  for  internal  (non-I/0)  operations,  although 
this  varies  from  one  implementation  to  another.  For  I/O 
efficiency,  there  is  little  indication  of  major  differences  among 
the  languages. 


2,3    Installation  Requirements 

The  last  set  of  requirements  are  those  imposed,  not  by  the 
application  to  be  implemented,  but  by  the  existing  and  potential 
resources  of  the  installation  doing  the  implementation.  Very  few 
installations  are  able  to  consider  each  project  de  novo;  more 
often,  new  systems  must  evolve  smoothly  from  existing  practice. 
Nonetheless,  DP  managers  should  not  neglect  the  possibility  of 
reaping  long-term  ongoing  benefits  simply  to  avoid  some 
short-term  costs. 


2.3,1    Language  Availability  - 

The  most  basic  issue  is  whether  the  installation  has  access 
to  a  processor  for  a  given  language.  Let  us  first  consider  the 
traditional  environment  with  one  central  large-  or  medium-size 
machine.  Given  a  project  of  any  size,  the  cost  of  an  additional 
compiler  can  usually  be  justified  if  the  language  offers 
substantial  benefits  over  those  already  available.  Language 
processors  may  be  obtained  either  from  the  hardware  vendor  or 
from  independent  software  firms,  or  accessed  through  timesharing. 
Sometimes  implementation  includes  the  procurement  of  hardware, 
and  in  these  cases,  language  availability  should  be  an  important 
factor  in  that  decision.  Very  often,  however,  language  selection 
will  be  limited  to  those  already  available  on  an  existing  system. 

The  advent  of  microcomputers  poses  some  new  issues  in  the 
choice  of  languages.  It  is  much  more  likely  that  implementation 
will  include  hardware  acquisition,  as  compared  to  the  use  of 
larger  machines.  The  cost  (per  system,  at  least)  of  hardware  and 
software  is  likely  to  be  relatively  low  -  hence  the  choice  among 
languages  can  be  a  freer  one.  As  with  the  procurement  of  large 
systems,  language  availability  for  a  proposed  microconputer 
should  be  carefully  considered  before  purchase.  The 
microcomputer  environment  has  been  dominated  by  BASIC,  C,  Pascal, 
and  to  some  extent  FORTRAN,  It  is  no  longer  unusual,  however,  to 
see  implementations  of  COBOL  or  PL/I  subsets,  and  at  least  one 
complete  implementation  of  COBOL  exists,  Ada  implementations,  of 
course,  are  not  as  yet  widespread  in  any  class  of  machine,  but 
some  are  being  developed  for  microcomputers  as  well  as  for  large 
machines. 


Page  5  0 


2.3.2    Compatibility  With  Existing  Software  - 

Very  often,  new  systems  must  interact  with  existing 
software.  Clearly,  this  interaction  is  simplified  when  the  same 
language  is  used.  Problems  may  arise  when  two  parts  of  a  system 
are  written  in  different  languages.  The  two  most  common  ways 
programs  of  different  languages  interact  are  1)  for  one  program 
to  call  another  as  a  subroutine,  and  2)  for  one  program  to  read 
files  written  by  another.  Unfortunately,  there  are  no 
inter-language  standards  addressing  these  two  areas,  and  users 
must  ensure  that  the  actual  implementations  of  the  languages  they 
will  employ  are  compatible  for  the  intended  purpose.  Note  that 
Ada  has  an  INTERFACE  pragma,  and  COBOL  an  ENTER  statement,  whose 
purpose  is  to  allow  communication  with  "foreign"  code. 
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3.0     LANGUAGE  SUMMARY   (SEE  FIGURE  17) 

In  this  section,  we  shall  recapitulate  briefly  the  topics 
covered  above  for  the  various  languages  and  point  out  their 
special  advantages  and  disadvantages.  Also,  the  committee (s) 
responsible  for  standardization  are  described.  Volume  2  contains 
program  examples  to  help  illustrate  the  style  and  approach  each 
language  encourages. 


3.1  Ada 

The  major  design  goal  of  Ada  is  the  ability  to  handle  large, 
real-time  applications,  with  a  premium  on  reliability  and 
portability.  The  whole  structure  of  the  language  is  driven  by 
these  requirements.  Ada's  tasking  facilities  and  representation 
clauses  support  efficient  real-time  operations.  The  extensive 
data-type  checking  and  exception-handling  support  reliability. 
Ada's  modularity  features,  such  as  packages  and  generics,  support 
the  construction  of  large  systems.  And  finally,  the  strong 
commitment  to  standardization  promotes  portability.  The  result 
is  a  language  which  is  very  well  suited  for  that  class  of 
applications. 

Ada  is  clearly  a  "professional's"  language.  There  is 
significant  overhead  when  learning  the  language  or  writing  a 
program.  Using  Ada,  the  programmer  has  the  power  to  construct 
complex  data  structures  and  algorithms.  Ada  is  a  big  language 
for  big  jobs.  Rather  than  build  many  facilities  into  the 
language,  the  choice  was  made  to  rely  on  Ada's  extensibility. 
Thus,  the  construction  of  application-specific  packages  is  a 
prerequisite  to  making  good  use  of  Ada  in  areas  beyond  those 
originally  envisioned. 

The  Ada  Joint  Program  Office  (AJPO)  within  the  Department  of 
Defense  is  the  sponsor  for  Ada  and  is  primarily  responsible  for 
development  and  maintenance  of  the  language.  Ada  was  adopted 
under  the  canvass  method  of  the  ANSI  procedures.  AJPO  has  set  up 
the  Ada  Validation  Organization  (AVO) ,  which  performs  validation 
testing  on  candidate  Ada  implementations. 

Ada  Joint  Project  Office 

3D 139    (4  00AN) 
The  Pentagon 

Washington  DC  20  301 


3.2  BASIC 

BASIC  was  originally  designed  as  a  vehicle  for  teaching 
students  elementary  concepts  of  computers  and  programming.  The 
goal  was  that  meaningful  results  could  be  obtained  with  very 
little      detailed      knowledge      of      the      language    or  machine. 
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Furthermore,  the  language  should  provide  meaningful  diagnostic 
messages  in  response  to  mistakes.  These  original  goals  have  been 
enlarged  to  include  the  incorporation  of  facilities  in  the 
language  to  support  the  most  common  applications:  data 
processing  and  numeric  calculation.  Nonetheless,  the  language 
has  remained  simple  in  concept;  for  instance,  by  default  there 
are  only  two  data-types,  variable-length  character  strings  and 
decimal  floating-point  numbers. 

The  result  is  a  language  for  end-users:  those  for  whom 
programming  is  a  secondary  skill.  BASIC^'s  emphasis  on  good 
diagnostics,  run-time  checking,  and  meaningful  defaults  all 
support  such  use.  The  language  is  therefore  an  appropriate  tool 
for  relatively  simple  interactive  applications.  BASIC  remains  a 
good  teaching  tool  at  the  introductory  level;  clearly  it  is  not 
meant  to  embody  more  advanced  concepts  of  computer  science,  but 
rather  to  provide  a  simple  accessible  way  for  beginners  to  learn 
about  programming. 

The  draft  standard  for  BASIC  has  been  developed  jointly  by 
three  committees,  ANSI/X3J2,  ECMA/TC21,  and  EWICS/TC2 . 
Responsibility  for  BASIC  within  ISO  is  held  by  TC97/SC5/WG13 . 


3.3  C 

The  main  design  goal  of  C  is  to  enable  relatively  portable 
systems  programming.  Consequently,  C  is  a  lower-level  language 
than  the  others  considered  here.  The  entities  of  the  language 
correspond  closely  to  typical  existing  hardware,  rather  than  to 
more  logical,  problem-oriented  concepts.  Thus,  the  absence  of 
record  I/O  and  the  inclusion  of  bit  operations  on  machine  words 
(presumably  equivalent  to  the  integer  type)  ,  register  variables, 
and  incrementing  and  decrementing  operations. 

C  would  normally  not  be  the  best  choice  for  applications 
programming.  Conversely,  no  other  language  is  likely  to  be  both 
as  portable  and  efficient  for  the  development  of  systems 
software,  such  as  I/O  drivers,  compilers,  utilities,  etc.  In 
particular,  C  should  be  used  wherever  possible  if  the  only 
alternative  is  assembler  language. 

Formal  standardization  work  on  C  started  only  recently. 
ANSI  committee  X3J11  is  currently  developing  a  draft 
specification. 


3.4  COBOL 

COBOL  is,  of  course,  the  pre-eminent  language  for  data 
processing  (business-type)  applications,  as  it  was  designed  to 
be.  Its  support  for  file  processing  and  editing  is  very  strong. 
As     a     secondary    benefit,     its    very     dominance     in  the  DP  arena 
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assures  that  a  great  deal  of  COBOL-oriented  commercial  software 
will  be  available.  There  are  weaknesses  in  the  language;  in 
particular  it  provides  little  support  for  interactive  I/O  and  its 
substring  manipulation  features  are  less  extensive  than  might  be 
expected.  Nonetheless,  it  is  likely  to  remain  the  dominant 
business  language  for  the  foreseeable  future.  While  COBOL  is 
often  thought  of  as  a  "main-frame"  language,  implementations  are 
becoming  increasingly  available  on  microcomputers.  Many  of  these 
compilers  conform  to  one  of  the  lower  levels  of  the  standard 
[NBS75]  ,  and  users  should  be  aware  of  which  features  are  included 
and  excluded  by  a  subset  under  consideration  for  purchase. 

The  development  of  COBOL  is  under  the  purview  of  the  CODASYL 
COBOL  Committee,  which  publishes  the  proposed  language 
specification  in  the  CODASYL  COBOL  Journal  of  Development.  ANSI 
committee  X3 J 4  has  primary  responsibility  for  standardization  of 
the  results  of  this  development  activity.  Internationally, 
TC97/SC5/WG8  and  ECMA/TC6  contribute  to  the  development  and 
maintenance  of  COBOL.     CODASYL" s  address  is: 

CODASYL:  CBEMA 

311  First  Street  NW,  Suite  500 
Washington,  DC  20001 


3.5  FORTRAN 

As  COBOL  dominates  business  applications,  so  FORTRAN  has 
come  to  dominate  scientific,  engineering,  and  mathematical 
applications.  FORTRAN  offers  a  broad  array  of  functions,  complex 
numbers,  and  perh^s  most  important,  a  very  substantial  base  of 
software.  FORTRAN  is  the  oldest  of  the  languages  under  study, 
and  its  age  is  reflected  in  several  shortcomings,  notably  its 
weak  support  for  software  maintenance.  Also,  there  are  no 
language  features  to  facilitate  processing  of  arrays  and  no 
recursive  procedures,  surprising  omissions  for  a  computational 
language.  While  FORTRAN  is  quite  suitable  for  applications  of 
moderate  size,  users  should  consider  other  languages  when 
embarking  on  a  major  development  effort.  FORTRAN  is  available  on 
a  wide  variety  of  machines.  Although  most  implementations  follow 
the  standard,  some  do  not.  Since  the  standard  ensures  support 
for  character  string  manipulation  and  some  structured 
programming,  users  are  well-advised  to  stay  with 
standard-conforming  processors. 


ANSI  committee  X3J3  has  primary  responsibility  for  language 
development  and  maintenance.  Internationally,  TC97/SC5/WG9 , 
ECMA/TC8,  and  EWICS/TCl  all  contribute  to  the  FORTRAN  effort. 
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3.6  Pascal 

Pascal  was  designed  as  a  vehicle  for  teaching  programming 
and  computer  science.  Consequently,  the  language  structure 
reflects  a  concern  for  conceptual  consistency  and  clarity. 
Pascal  has  become  quite  successful  in  fulfilling  this  design 
goal;  it  is  probably  the  most  common  language  used  in  college 
level  computer  science  courses.  Certain  features  used  in  common 
applications,  but  which  are  less  important  pedagog ic ally ,  were 
omitted,  e.g.,  string-handling,  enhanced  numeric  data-types  and 
operations,  and  external  procedures.  Thus,  Pascal  is  not 
especially  well  suited  to  DP  or  scientific  applications. 
Moreover,  the  language  is  complex  enough  that  it  is  not 
appropriate  for  casual  use.  Pascal  has  been  used  successfully 
for  certain  classes  of  systems  programming,  such  as  parsers, 
which  are  not  strongly  dependent  on  the  underlying  hardware. 

There  is  active  effort  on  Pascal  standardization  in  both  the 
national  and  international  arena.  Nationally,  ANSI/X3J9  and  the 
ILSE  Pascal  Standards  Committee  have  combined  to  form  the  Joint 
Pascal  Committee.  Within  ISO,  TC97/SC5/WG4  has  responsibility 
for  Pascal. 

Within  North  America,  the  authorized  distribution  agent  for 
the  Pascal  Validation  Suite  developed  by  Professor  Arthur  Sale  of 
the  University  of  Tasmania,  and  others,  is: 

Software  Consulting  Services 
Ben  Franklin  Technology  Center  125 
Murray  H,  Goodman  Campus 
Lehigh  University 
Bethlehem  PA  18  015 
(215)  861-7920 

The  British  Standards  Institution  offers  a  Pascal  Validation 
Service,  which  is  based  on  the  ISO  standard. 


3.7  PL/I 

PL/I  was  designed  to  be  a  truly  general-purpose  programming 
language:  one  which  would  support  the  great  majority  of  end -user 
and  systems  applications.  Thus,  the  language  contains  a  large 
number  of  features:  a  wide  assortment  of  data-types,  strong  file 
support,  and  detailed  control  of  storage.  Moreover,  all  the 
structuring  features  of  modern  languages  are  implemented,  e.g.  , 
blocks  and  recursion.  PL/I  is  certainly  capable  of  handling  the 
applications  it  was  designed  for.  Because  its  features  are 
built-in  and  standardized,  the  language  can  be  used  for  writing 
portable  programs,  without  recourse  to  libraries  of  user-defined 
routines.  Especially  in  the  case  of  applications  which  overlap 
several  of  the  traditional  categories  (business,  scientific, 
systems)  ,  the  breadth  of  PL/I  provides  a  unique  advantage. 
Because     the    language    is    so    powerful,     it     is    also  large  and 
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complex^  The  rules  for  defaults  and  data  conversion  are 
difficult  to  master*  Somewhat  like  Ada,  PL/I  is  a  powerful 
language  for  use  by  professional  programmers  in  large 
applications.     For  simpler  applications,   simpler  tools  exist. 

Unfortunately,  the  full  PL/I  standard  has  not  been  widely 
implemented,  so  added  to  the  complexity  of  the  language  itself  is 
the  variation  among  compilers.  As  mentioned  earlier,  the  PL/I 
subset  standard  [PL/181]  has  achieved  broader  acceptance.  ANSI 
X3J1  and  SC5/WG11  are  the  committees  primarily  responsible  for 
PL/ 1  standards. 


4,0  CONCLUSION 

When  an  application  is  to  be  implemented  with  conventional 
programming,  the  choice  of  language  can  have  a  major  effect  on 
the  success  of  the  project.  Moreover,  the  user  must  carefully 
consider  the  costs  and  benefits  not  only  during  development,  but 
also  throughout  the  life  of  the  application.  In  many  cases, 
maintenance  costs  exceed  development  costs.  While  it  is  not 
possible  to  formulate  a  precise  method  for  choosing  the  best 
language,  a  review  of  the  criteria  presented  in  this  report  will 
help  at  least  to  avoid  the  worst  choices. 


It  can  hardly  be  emphasized  too  strongly  that  users  should 
not  ignore  long-term  costs  and  benefits.  For  small  short-term 
projects,  the  total  risk  is  low  in  any  case.  But  for  larger 
projects,  many  indirect  criteria  may  become  crucial.  In 
particular,  it  can  be  a  decisive  advantage  when  a  language  is 
supported  by  strong  standardization. 
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ABBREVIATIONS 


Association  for  Computing  Machinery,  scientific  and 
technical  association  with  broad  interest  in  computers, 
academic  orientation, 

Ada  Joint  Project  Office,  agency  within  Department  of 
Defense  with  primary  responsibility  for  Ada  standards, 
sponsor  of  Ada  as  ANSI  standard. 

American  National  Standards  Institute,  organization 
fostering  voluntary  national  standards. 

Ada  Validation  Organization,  set  up  by  AJPO  to 
administer  validation  of  Ada  implementations. 

British  Standards  Institution,  organization  fostering 
voluntary  national  standards  in  the  United  Kingdom, 
offers  Pascal  Compiler  Validation  Service. 

Computer  and  Business  Equipment  Manufacturers 
Association,  American  trade  association,  provides 
secretariat  for  X3 . 

Conference  on  Data  System  Languages,  committee 
responsible  for  the  development  (but  not 
standardization)   of  COBOL  specifications. 

European  Computer  Manufacturers  Association,  European 
trade  association,  participates  actively  in  ISO/TC97 
standardization  activities. 

European  Workshop  on  Industrial  Computer  Systems, 
organization  concerned  with  language  control  of 
real-time  systems. 

Federal  Information  Processing  Standard,  authorized  by 
the  Department  of  Commerce  to  manage  information 
processing  activities  within  the  Federal  Government, 
developed  and  issued  by  ICST/NBS. 
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FQTC  Federal      Software      Testing      Center,       within        GSA , 

administers  validation  tests  for  FIPS  languages. 

GSA  General    Services      Administration,       responsible  for 

property  management  within  the  Federal  Government, 
parent  body  of  FSTC. 

ICST  Institute    for    Computer      Sciences      and  Technology, 

administers  FIPS  program  for  the  Federal  Government, 
assists  Federal  agencies,  performs  research  in 
computers  and  networks, 

lEEE/CS  Institute  of  Electrical  and  Electronics  Engineers 
Computer  Society,  professional  association  with  broad 
interest  in  computer Se 

ISO  International      Organization        for  Standardization, 

organization  fostering  voluntary  international 
Standards. 

NBS  National    Bureau    of    Standards,     agency    with  primary 

responsibility    for  measurement  methods,   standards,  and 
-  data  for  physical  and  engineering  sciences    within  the 

Federal  Government,  parent  body  of  ICST. 

NTIS  National  Technical  Information  Service,  sells  technical 

products  developed  for  and  within  the  Federal 
Government. 

SC5  Subcommittee  5  -  Programming    Languages,     of  ISO/TC97, 

has  primary  responsibility  for  language  standards 
within  ISO.  Individual  languages  handled  by  working 
groups  (WG'^s)  within  SC5  (see  Appendix  B.5  concerning 
re-organization)  . 

TC97  Technical    Committee    97      ■-      Information  Processing 

Systems,  has  primary  responsibility  for  computer 
standards  within  ISO,  parent  body  of  SC5  (see  Appendix 
B.5  concerning  re-organization). 

X3  X3     -     Information    Processing    Systems,     the  American 

National  Standards  Committee  for  computer  standards 
operating  under  the    procedures    of    ANSI,  Individual 

languages  handled  by  "J"  technical  subcommittees,  e.g.  , 
X3J1  for  PL/I. 


APPENDIX  B 
SOURCES  OF  INFORMATION 


In  addition  to  the  organizations  mentioned  in  section  3 
which  work  with  individual  languages,  there  are  several  bodies 
with  a  general  interest  in  programming  languages  and  computer 
standards.  Below  is  a  brief  description  of  the  areas  of  concern 
and  mailing  address  and  telephone  number  for  the  most  prominent 
of  these  bodies. 


B.l     INSTITUTE  FOR  COMPUTER  SCIENCES  AND  TECHNOLOGY 

The  Institute  for  Computer  Sciences  and  Technology  (ICST) 
within  the  National  Bureau  of  Standards  (NBS)  has  responsibility 
for  Federal  Information  Processing  Standards,  providing  technical 
assistance  to  Federal  agencies,  and  conducting  research  in 
computer  and  network  technology.  ICST  participates  actively  in 
voluntary  industry  standards  development  activities,  including 
programming  languages.  Within  ICST,  the  Center  for  Programming 
Science  and  Technology  is  responsible  for  programming  language 
standards. 

Institute  for  Computer  Science  and  Technology 
Center  for  Programming  Science  and  Technology 
Data  Management  and  Programming  Languages  Division 
Building  225,  Room  A- 255 
National  Bureau  of  Standards 
Gaithersburg,  MD  20899 
(301)  921-2431 


B.2     FEDERAL   SOFTWARE  TESTING  CENTER 

The  Federal  Software  Testing  Center  (FSTC)  within  the 
General  Services  Administration  (GSA)  participates  in  the 
administration  of  the  GSA  procurement  regulations  for  the  Federal 
Government.  In  particular,  FSTC  maintains  and  applies  validation 
systems  for  the  various  languages  approved  for  Federal  use 
(currently  COBOL,  FORTRAN,  and  Minimal  BASIC).  Also,  FSTC 
maintains  a     register     [FSTC84]     of    implementations    which  have 
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undergone  this  validation  process  and  are  thus  eligible  for 
Federal  procurement.     This  register  includes  Ada  compilers. 

Federal  Software  Testing  Center 
Two  Skyline  Place,  Suite  1100 
5203  Leesburg  Pike 
Falls  Church,  VA  22041 
(703)  756-6153 


B.3     NATIONAL  TECHNICAL  INFORMATION  SERVICE 

The  National  Technical  Information  Service  (NTIS)  within  the 
Department  of  Commerce  serves  as  a  clearinghouse  for  technical 
publications  developed  for  and  within  the  Federal  Government. 
ICST  publications  and  software  products  are  normally  available 
for  purchase  through  NTIS. 

National  Technical  Information  Service 
5  28  5  Port  Royal  Road 
Springfield,  VA  22161 
(703)  487-4600 


B.4     X3  -   INFORMATION  AND  PROCESSING  SYSTEMS 

X3  is  an  American  National  Standards  Committee  operating 
under  the  procedures  of  the  American  National  Standards  Institute 
(ANSI).  There  are  technical  subcommittees  within  X3  (see  Figure 
15)  for  all  the  languages  in  this  report  except  Ada.  An  ANSI 
standard  is  voluntary.  Participation  by  all  those  concerned  with 
standards  (producers,  consumers,  and  others)  is  encouraged.  The 
X3  secretariat  is  held  by  the  Computer  and  Business  Equipment 
Manufacturers  Association  (CBEMA) . 

X3  Secretariat:  CBEMA 
311  First  Street  NW,  Suite  500 
Washington,  DC  20001 
(202)  737-8888 


B.5     SC5  -  PROGRAMMING  LANGUAGES 

SC5  is  a  subcommittee  of  the  International  Standards 
Organization's  (ISO)  TC97  -  Information  Processing  Systems.  It 
is  the  body  which  co-ordinates  international  development  and 
approval  of  language  standards.  The  secretariat  for  ISO/TC97/SC5 
is  currently  held  by  ANSI.  At  the  time  of  this  writing,  TC97  is 
being  re-organized,  and  the  language  standardization  work  is 
being  assigned  to  two  new  subcommittees,  SC21  -  Information 
Retrieval,  Transfer,  and  Management  for  OSI  and  SC22 
Application  Systems  Environments  and  Programming  Languages. 
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SC5  Secretariat:  ANSI 
14  30  Broadway 
New  York,  NY  10018 
(212)  354-3347 


B.6     IEEE  COMPUTER  SOCIETY 

While  traditionally  more  concerned  with  hardware  issues,  the 
IEEE  Computer  Society  (lEEE/CS)  has  recently  taken  a  more  active 
role  in  programming  languages.  It  is  co-operating  with  X3  (see 
above)  on  the  standardization  efforts  for  Pascal,  Also,  IEEE  is 
proposing  standards  for  floating-point  arithmetic  which  will  have 
important  language  implications, 

IEEE  Computer  Society 
1109  Spring  Street,  Suite  300 
Silver  Spring,  MD  20910 
(301)  589-8142 


B.7     SPECIAL  INTEREST  GROUP  ON  PROGRAMMING  LANGUAGES 

The  Special  Interest  Group  on  Programming  Languages 
(SIGPLAN)  of  the  Association  for  Computing  Machinery  (ACM)  is  a 
scientific  and  technical  association  devoted  to  the  exploration 
of  various  language  issues.  Their  informal  publication,  "SIGPLAN 
Notices",  covers  topics  of  current  interest,  ACM  also  publishes 
a  formal  quarterly  journal,  "Transactions  on  Programming 
Languages  and  Systems". 

ACM  Headquarters 
11  West  4  2nd  Street 
New  York,  NY  100  36 
(212)  869-7440 


APPENDIX  C 
ALTERNATIVES  TO  CONVENTIONAL  PROGRAMMING 


Historically,  high-level  programming  languages  made  possible 
a  great  improvement  in  programmer  productivity  because  they 
allowed  the  user  to  express  algorithms  and  data  structures  in  a 
comparatively  problem-oriented  way,  as  opposed  to  the  hardware 
orientation  of  machine  and  assembler  languages  [Samm69]  .  There 
was,  of  course,  a  price  to  be  paid:  some  loss  in  run-time 
efficiency  and,  perhaps  more  important,  the  inability  to  access 
directly  all  the  hardware  capabilities  of  a  system.  For 
instance,  the  FORTRAN  programmer,  as  such,  cannot  do  fixed-point 
decimal  arithmetic,  even  if  the  hardware  supports  it. 
Nonetheless,  no  one  would  seriously  argue  today  that  assembler 
language  should  be  used  routinely  for  most  applications;  the 
gain  in  programmer  productivity  far  outweighs  the  costs  just 
mentioned. 


Many  experts  believe  that  the  practice  of  application 
development  and  maintenance  is  now  on  the  verge  of  a  transition 
comparable  to  that  between  assembler  and  high-level  languages 
[Mart82],         [Wass82].  Traditionally,       the      task      of  the 

programmer/analyst  has  been  to  devise  algorithms  that  solve  the 
problem  presented  by  the  end-user.  The  programmer  figures  out 
how  to  solve  the  problem  and  then  expresses  that  solution  in  a 
programming  language.  Techniques  are  becoming  available  (see 
below)  which  will  allow  the  programmer,  or,  better  still,  the 
end-user,  to  state  more  or  less  formally  what  results  are 
desired.  The  system  is  then  capable  of  producing  these  results 
automatically.  At  no  time  does  a  human  need  to  generate  an 
explicit  algorithm.  The  new  approach  is  usually  described  as 
"functional"  as  distinguished  from  "procedural"  programming. 

The  analogies  with  the  previous  transition  to  high-level 
languages  are  apparent.  Earlier,  DP  practitioners  were  freed 
from  thinking  about  irrelevant  hardware  details;  now  they  may  be 
freed  from  thinking  about  irrelevant  algorithmic  details.  For 
instance,  the  end-user  is  interested  in  updating  the  personnel 
file.  The  fine  points  of  the  associated  merge  algorithm  are  only 
incidental  to  solving  the  problem.  And,  as  before,  there  is  a 
price.  It  may  be  expected  that  there  will  be  some  degradation  of 
run-time  efficiency.  Again,  there  will  be  a  loss  of  "fine 
control"    -    users  will  depend  on  the  stereotyped  solutions  built 
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into  the  new  tools.  Finally,  just  as  high-level  languages  have 
not  abolished  assembler  programming,  but  merely  restricted  it  to 
those  relatively  few  cases  where  machine  efficiency  and  fine 
control  are  critical,  it  is  safe  to  predict  that  there  will  be  a 
continuing  need  for  conventional  programming  for  the  foreseeable 
future,  both  for  some  new  development,  and  certainly  for 
maintenance  of  existing  systems. 

There  is  one  aspect  of  this  transition  from  conventional 
programming  to  functional  techniques  which  is  not  analogous  to 
the  earlier  transition  from  assembler  language:  almost  all  the 
popular  languages  are  now  standardized  to  some  degree,  whereas 
functional  techniques  are  not.  Thus  a  system  written  in 
(standard)  COBOL  does  not  depend  in  a  crucial  way  on  the  support 
of  any  particular  vendor,  or  on  a  given  machine  architecture. 
The  same  cannot  be  said  (yet)  of  many  of  the  functional 
approaches  mentioned  below. 

When  should  one  use  conventional  programming  languages  and 
when  functional  techniques?  This  issue  is  a  matter  of  some 
debate;  see  [Marts  2]  for  an  articulate  statement  of  the 
"pro-functional"  position  and  [Zveg83]  for  a  spirited  rejoinder. 
A  short  answer  is  that  the  smaller,  simpler,  and  more  typical  the 
application,  the  more  susceptible  it  will  be  to  the  new 
functional  techniques.  Also,  functional  techniques  tend  to  be 
associated  with  applications  which  are  short-term  or  single-user 
or  both,  because  of  their  relative  advantages  with  respect  to 
development  time  and  required  skills,  and  disadvantages  with 
respect  to  machine  efficiency  and  standardization.  Because  of 
the  relatively  short  start-up  time,  the  functional  approach  may 
also  prove  valuable  when  a  system  is  to  be  designed  with  the  aid 
of  prototypes.  Typically,  the  overhead  of  conventional 
programming  is  too  great  to  allow  the  development  of  software 
only  for  the  purpose  of  system  design.  On  the  other  hand, 
insofar  as  fine  control,  standardization,  and  run-time  efficiency 
are  required,  conventional  programming  is  more  likely  to  be  the 
better  approach.  For  example,  a  large,  long-lived,  logically 
complex  system  with  high  transaction  rates  would  very  likely  not 
be  amenable  to  functional  implementation  techniques. 

There  is  as  yet  no  precise  way  to  evaluate  the  complex 
trade-offs  involved  in  deciding  between  conventional  programming 
and  functional  techniques.  ICST  plans  to  keep  these  issues  under 
study  and  will  issue  more  detailed  guidance  as  experience  with 
the  new  techniques  accumulates.  Those  interested  in  the 
functional  techniques  should  find  the  following  publications 
helpful:     [HechSx]  ,    [Hech8  4]  . 

The  following  sub-sections  describe,  very  briefly,  some  of 
the  alternatives  to  conventional  high-level  programming  as  a 
means  of  developing  and  maintaining  applications.  These 
descriptions  should  not  be  taken  as  a  detailed  guideline  on  usage 
and  selection,  but  merely  as  an  indication  of  the  major 
approaches  which  are  currently  available. 
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C.l     DATABASE  MANAGEMENT  SYSTEMS 

While  it  does  not  always  constitute  a  complete  application 
development  method,  the  use  of  a  database  management  system 
(DBMS)  is  often  the  basis  for  other  techniques  [Gall8  4] .  For 
instance,  an  automatic  report  generator  may  presuppose  the 
existence  of  a  database  from  which  the  report  is  to  be 
constructed.  Of  course,  DBMS  facilities  may  also  be  accessed 
from  conventional  programming  languages.  In  either  case,  the 
establishment  of  an  integrated  database  for  a  functional  area 
will  very  often  enable  the  use  of  more  powerful  software 
development  technologies. 


C.2     QUERY  AND  REPORT  FACILITIES 

Query  and  report  facilities  are  perhaps  the  best  established 
of  the  functional  techniques.  RPG  and  COBOL' s  Report  Writer  have 
been  available  for  many  years  and  provide  good  examples  of  the 
functional  approach.  The  user  specifies  the  information  to  be 
displayed  and  some  indication  of  the  desired  format.  The  system 
generates  the  required  report.  At  no  time,  for  instance,  does 
the  user  explicitly  formulate  the  logic  necessary  to  handle 
control  breaks  or  page  headings.  Many  database  management 
systems  have  an  associated  query  language  that  allows  the  user  to 
display  information  from  the  database.  Query  and  reporting  are 
highly  susceptible  to  a  functional  approach  because  they  are,  by 
definition,  read-only  operations;  the  file  or  database  is  not 
changed.  Updating  typically  requires  more  control,  such  as 
editing  and  internal  consistency  checking. 


C.3     APPLICATION  PACKAGES 

Application  packages  are  systems  written  to  handle  certain 
common  applications,  such  as  payroll  or  inventory.  Normally, 
they  are  parameterized  so  that  each  user  can  tailor  the  system  to 
his  particular  specifications.  To  the  extent  that  a  user's 
requirements  are  typical  of  the  application,  and  the  application 
itself  is  a  common  one,  it  is  likely  that  an  adequate  package 
will  be  available.  Conversely,  highly  specialized  applications 
probably  should  not  be  implemented  with  an  application  package. 
See  [Fran84]  for  further  guidance. 


C.4     APPLICATION  GENERATORS 

Application  generators  accept  some  high-level  specification 
of  the  work  to  be  done  and  then  produce  programs  (either  source 
or  object  code)  to  accomplish  that  task.  If  the  generated  code 
is  in  source  form,  then,  of  course,  the  user  is  free  to  modify  it 
directly.     Thus,   there  may  still  be    a    problem    of    source  code 
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maintenance  (and  standardization)  ,  unless  the  user  is  committed 
to  changing  the  application  only  through  the  generator  itself. 
Generators  usually  provide  an  escape  mechanism,  so  that  users  can 
code  certain  crucial  parts  of  the  system  by  hand. 

C.5     VERY  HIGH-LEVEL  LANGUAGES 

It  is  an  open  question  which  languages  qualify  as  "very 
high-level."  In  [Mart82],  the  term  is  applied  to  APL,  NOMAD,  and 
MAPPER,  because  they  provide  powerful  operations  for  data 
manipulation  not  found  in  languages  such  as  Pascal  or  PL/I. 
Others  use  the  term  to  refer  to  more  research-oriented  languages, 
such  as  SETL  and  FFP  [SammSl]  .  In  any  event,  these  languages 
encourage  a  more  functional  (and  therefore  less  procedural)  style 
of  programming  than  do  the  traditional  algorithmic  languages. 


C.6     ASSEMBLER  LANGUAGE 

Another  alternative,  albeit  not  a  new  one,  to  the  use  of 
high-level  languages  is  the  use  of  assembler  language.  There 
remain  applications  for  which  direct  control  over  the  hardware  or 
run-time  efficiency  is  so  important  that  assembler  programming  is 
justified.  We  should  stress  that  it  is  a  rare  application  which 
must  be  programmed  completely  in  assembler.  More  often,  a 
relatively  small  piece  of  code  accounts  for  a  high  percentage  of 
execution  time,  or  is  inherently  machine-dependent.  In  such 
cases,  it  is  reasonable  to  program  the  critical  section  of  code 
in  assembler,  while  most  of  the  system  is  expressed  in  some 
higher-level  language.  Note  also  that  the  "mid-level"  language  C 
can  often  be  used  in  place  of  true  hardware-or iented  assembler, 
with  comparable  efficiency.     C  is  covered  below  in  detail. 


C.7     MANUAL  OPERATIONS 

There  is  always  some  cost  associated  with  automating  an 
application  (e.g.,  for  hardware,  for  the  staff  time  to  develop 
and  operate  the  system)  .  When  a  system  is  implemented  through 
conventional  programming,  this  cost  is  not  likely  to  be 
negligible.  Therefore,  it  is  reasonable  to  ask  whether 
automating  a  given  application  is  worth  the  effort.  It  is  not 
clear,  for  instance,  that  much  is  gained  by  having  an  appointment 
schedule  implemented  on  a  personal  computer  rather  than  in  a 
notebook . 
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